[Emerging-Sigs] JA3 flags official Firefox distribution sites as malware

Nelson, Cooper cnelson at ucsd.edu
Mon Oct 28 13:37:30 HDT 2019

Was waiting for you to go first, Michal!  I’m seeing lots of JA3 alerts inbound against our own infrastructure, which I’m fairly certain are also false-positives, so don’t take it personally.  I agree that there seems to be a flaw in the core design, vs. a typical false-positive scenario.

Our alerts went from 3-4 million a day to 15+ million with the JA3 alerts enabled.   I’ve been trying to filter a signal from the resulting noise with little to show for it currently, as every active host on campus is triggering 100+ alerts a day without any sort of meaningful pattern to it that I can discern.  I was skeptical of JA3 from the beginning as the whole point of TLS is prevent any sort of meaningful information leakage from the secure channel in the first place, so this does not surprise me.

We have local webservers triggering alerts against *everything*, malware, phishing, RATs, etc.  Or maybe this *is* by design, as according to the docs they seem to be targeting a zero trust environment (which isn’t us!) and is likely going to result in a lot of collisions:

“JA3 is also an excellent detection mechanism in locked-down environments where only a few specific applications are allowed to be installed. In these types of environments one could build a whitelist of expected applications and then alert on any other JA3 hits.”

However, this is along the lines of my prior request for ASN based reputation support in suricata.  For example, we could create a standard list of “known good” ASNs, eg:


… and only alert against “known bad” or “unknown” ASNs.  So we only escalate to an alert if there are at least two independent IOCs.

That said, I have seen at least one case where a single host triggered multiple JA3 malware alerts from the same family, along with some other associated ETPRO alerts, so those were likely legit.  So, for us at least, they could function as a secondary IOC to be evaluated in context with other bad behavior.  Part of my basic philosophy is that ‘noise is good’ as it creates rich opportunities for data mining, however even I have my limits and will turn spammy sigs off, like the iTunes/iPhone fluff.  I’m probably going to have to put JA3 in that bucket for now because at this point they are clogging up our alerting pipeline/SIEM.

For those able to afford the IP reputation feed from ETPRO, one could escalate alerts to your SOC based on a combination of a JA3 and poor IP reputation.

For the rest of us, maybe EmergingThreats could either do something with flowbits to only throw an alert if the source or destination IP has already been tagged recently (within a few minutes) as doing something ‘bad’.  It would also be nice, if possible, to split the file into low and high confidence alerts.

The EmergingThreats team should also set the $HOME_NET variable by default for all the client malware alerts, to get rid of the inbound false-positives at least.


From: Emerging-sigs <emerging-sigs-bounces at lists.emergingthreats.net> On Behalf Of Michal Purzynski
Sent: Monday, October 28, 2019 2:20 PM
To: emerging-sigs at lists.emergingthreats.net
Subject: [Emerging-Sigs] JA3 flags official Firefox distribution sites as malware

Anyone having any luck with those new signatures? I believe they are flawed by design. JA3, having tons of collisions, has never been intended for a detection, especially used in a signature "if A then ALARM".

On top of that, you're flagging official Firefox distribution sites as malware. I think I know what's going on, as it used to be the case in the past

1. someone, somewhere, takes the official installer and backdoors it. This invalidates the binary's signature, but user's don't care ;)
2. the backdoored version downloads the Firefox from us and a malware from somewhere else
3. the sandbox that's responsible for generating signatures, just flags every kind of traffic egreesing from the system as "malware related"
4. boom, we're on the list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20191028/169cfe8a/attachment-0001.html>

More information about the Emerging-sigs mailing list