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

Jason Williams jwilliams at emergingthreats.net
Mon Oct 28 15:00:32 HDT 2019


Appreciate all the feedback everyone, good points all around!

We're moving towards using detection methods where we're not going to
solely rely on the ja3 by itself, but instead using flowbits for tying it
to the ja3s or other various traffic aspects as mentioned.

Presently there are 122 rules in the ET OPEN JA3 rule file (sourced from
public hash lists related to malware and some community contributions) and
only an additional 2 in the ETPRO JA3 rule file. If you have more than
that, you may need to update your rules. Previously we had many more ET
OPEN JA3 rules in the set, but those were deleted a bit ago as, yes, too
much noise. If you're re-enabling them and running them out of the
deleted.rules file, noise is why they were sent there.

If you are seeing FPs against an active rule, please let us know what rule
and any relevant data so that we can tune it or nuke it.
https://feedback.emergingthreats.net/ is generally the fastest way to get
things in our queue.

All your viewpoints of how these rules act on your different networks is
extremely valuable for improving the ruleset for everyone, so thank you
very much for letting us know how it's impacting your day to day.

On Mon, Oct 28, 2019 at 5:19 PM Jason Taylor <jtfas90 at gmail.com> wrote:

> We had similar results as it sounds like you all are having with ja3.
>
> I haven't had a chance to run the set of ja3 rules but what we found in
> general with ja3 was that we had to write rules that looked at both ja3 and
> ja3s (i.e. flowbits)
>
> We also knocked down the ja3/ja3s rules to target specific things that we
> otherwise didn't have an otherwise good way to detect. For instance
> specific things like cobalt strike or meterpreter/metasploit c2.
>
> On a side note has anyone put ja3 hashes in a dataset? Was thinking about
> that the other day and was curious if anyone has messed around with it yet?
>
> JT
>
> On Mon, Oct 28, 2019, 18:37 Nelson, Cooper <cnelson at ucsd.edu> wrote:
>
>> 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:
>>
>>
>>
>> https://ipinfo.io/AS36856
>>
>>
>>
>> … 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.
>>
>>
>>
>> -Coop
>>
>>
>>
>> *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
>>
>>
>> _______________________________________________
>> Emerging-sigs mailing list
>> Emerging-sigs at lists.emergingthreats.net
>> https://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>
>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>> http://www.emergingthreats.net
>>
>> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at lists.emergingthreats.net
> https://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro
> http://www.emergingthreats.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20191028/5651a612/attachment.html>


More information about the Emerging-sigs mailing list