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