I tried matching a tls alert on a hash that came from a pcap file from TLS version 1.3 but the alert never went of changed to a pcap file where the rule matched a hash from TLS 1.2 and it worked has this something to do with the protocol or is this a suricata issue?
Used this exact same rule only changed the hash from the pcap files
alert tls any any → any any (msg:“match JA3 hash”;ja3_hash; content:“871a754af286dfb70c1b53c6887c62e0”;sid:100001;)
Weird enough i just tried a diffrent pcap and its detecting it
file
tls1 WORKS
tls3 WORKS
tls_mine DOESNT work here are the rules
alert tls any any → any any (msg:“ET JA3 Hash - Possible Malware - Dridex”; ja3_hash; content:“871a754af286dfb70c1b53c6887c62e0”; reference:url,trisulnsm (Trisul Network Analytics ) · GitHub>
alert tls any any → any any (msg:“match JA3 hash match”;ja3_hash; content:“a66e498c488aa0523759691248cdfb01”;sid:100011;)
alert tls any any → any any (msg:“match JA3 hash doesnt match”;ja3_hash; content:“ea39e432bc0bf3ded25f0913860a63df”;sid:100012;)
But that only comes after shouldn`t the rule trigger when it sees the client hello ja3 hash?
Also i took tls1 and tls3 from the web the other one was captured by me
JA3 is indeed supposed to match on the Client Hello, which is also present in tls_mine.pcapng.
Here’s what caught my eye though:
In tls_mine.pcapng, there is no TCP handshake, so maybe the stream isn’t actually inspected as it should.
In tls_mine.pcapng the JA3 hash, according to Wireshark, is ea034632bc22bbd167557e4b70939465 which does not appear in any of your rules. In the others (tls3.pcapng → a66e498c488aa0523759691248cdfb01, tls1.pcapng → 871a754af286dfb70c1b53c6887c62e0) the JA3 hashes match what is in the rules. So could it be that your rule you are just looking for the wrong hash? Indeed, when I change the hash in your last rule to be
alert tls any any -> any any (msg:"match JA3 hash doesnt match";ja3_hash; content:"ea034632bc22bbd167557e4b70939465";sid:100012;)
Note that I also set -k none to avoid checksum issues in the pcap and --set stream.midstream=true to enable inspection without having seen a TCP session handshake.
Using Debian’s Wireshark 4.0.11 (Git v4.0.11 packaged as 4.0.11-1~deb12u1).
pyja3 also agrees with my hash:
/tmp via 🐍 v3.11.2 (test1) took 6s
❯ pip install pyja3
Collecting pyja3
Downloading pyja3-1.0.0.tar.gz (4.9 kB)
Preparing metadata (setup.py) ... done
Collecting dpkt
Downloading dpkt-1.9.8-py3-none-any.whl (194 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 195.0/195.0 kB 468.4 kB/s eta 0:00:00
Installing collected packages: dpkt, pyja3
DEPRECATION: pyja3 is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
Running setup.py install for pyja3 ... done
Successfully installed dpkt-1.9.8 pyja3-1.0.0
/tmp via 🐍 v3.11.2 (test1)
❯ tshark -F pcap -r ~/Downloads/tls_mine.pcapng -w ~/Downloads/tls_mine.pcap
/tmp via 🐍 v3.11.2 (test1)
❯ ja3 ~/Downloads/tls_mine.pcap
[
{
"destination_ip": "152.199.19.160",
"destination_port": 443,
"ja3": "771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,17513-27-35-51-23-16-11-10-13-5-65281-45-65037-18-43-0-41,29-23-24,0",
"ja3_digest": "ea034632bc22bbd167557e4b70939465",
"source_ip": "158.64.20.39",
"source_port": 39648,
"timestamp": 1713186125.557637
}
]
Well that’s interesting had version 3.6.2 of wireshark installed just updated it and its working now.Thank you a lot for the help even thought wasnt suricata.
