This Zeek plugin will save the following fields to spl.log in the logging directory.

• uid - The related SSL session's unique identifier.
• orig_spl - A vector of configurable length (default 20), containing the lengths of encrypted payloads from the session originator
• resp_spl - A vector of configurable length (default 20), containing the lengths of encrypted payloads from the session responder
• orig_spt - A vector of configurable length (default 20), containing the time interval between encrypted payloads from the session originator
• resp_spt - A vector of configurable length (default 20), containing the time interval between encrypted payloads from the session responder

Cisco researchers performed a study with the goal of identifying malicious network traffic when it uses TLS. In this study, they showed that a random-forest model, as implemented by SciKit-Learn, can be made up to 30% more accurate by including data on per-payload sizes and per-payload intervals. Other research has supported this claim.

By creating a log containing this data, I hope to enable the creation of new and interesting analytics to detect malware using TLS to communicate.

If cloned from source:

$ zkg install .

Alternatively, you could copy spl-spt.zeek into /opt/zeek/share/zeek/site/spl-spt/, then add the following to local.zeek

@load ./spl-spt

If using Zeek > 3.0 or a Zeek-product, like Corelight:

zkg install spl-spt

For what it's worth, I highly recommend enabling JSON logging by adding the following to local.zeek

@load tuning/json-logs.zeek 

If you want the vectors to be larger (or smaller) in length, edit the following values inside local.zeek after the package is loaded.

• SPL::spl_length - The length of the two payload-length vectors
• SPL::spt_length - The length of the two payload-time vectors

As Anthony Kaza points out, the generated data is not actually the length/interval of packets, it is the interval between TLS encrypted records. This oversight was because my original implementation generated this data using the tcp_packet event, where the length parameter is actually the length of the packet. Due to performance considerations, I elected to generate the data only when DPD identifies a SSL/TLS session, and then only for the encrypted data transfer, by using the ssl_encrypted_data event.

Unfortunately, at that point I was already committed to the "SPL-SPT" acronym. As such, I renamed this package to "Sequence of Payload Lengths," which, while still not wholly correct, is at least closer to correct.

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

http://ccr.sigcomm.org/online/files/p7-williams.pdf

https://dl.acm.org/doi/pdf/10.1145/3097983.3098163