MB Secure

View Original

Hunting with JA3

Marcus Bakker

Within this blog post I will explain how JA3 can be used in Threat Hunting. I will discuss a relative simple hunt on a possible way to identify malicious PowerShell using JA3 and a more advanced hunt that involves the use of Darktrace and JA3.

What is JA3?

Introduction

JA3 is a method to fingerprint a SSL/TLS client connection based on fields in the Client Hello message from the SSL/TLS handshake. The following fields within the Client Hello message are used: SSL/TLS Version, Accepted Ciphers, List of Extensions, Elliptic Curves, and Elliptic Curve Formats. The end result is a MD5 hash serving as the purpose for the fingerprint. Because the SSL/TLS handshake is sent in clear text we can use it to fingerprint any client application using the information within the Client Hello message.

At the time of writing JA3 is being supported by:

  • Bro

  • Darktrace

  • MISP

  • Moloch

  • NGiNX

  • RedSocks

  • Trisul NSM

  • Python script that accepts a PCAP file (you can find this one on the GitHub page of JA3)

For more detailed info on JA3 see: https://github.com/salesforce/ja3

Uniqueness of the fingerprint

It is not uncommon to see that a particular JA3 hash is also being used by another type of application. For example: applications written in Java tends to result in the same JA3. You will also notice, depending on the Windows version, when looking at PowerShell that the same JA3 hash is also being used by the Windows Background Intelligence Transfer Service (BITS).

It is important to take collisions into account when performing investigations based on JA3 (please note I am not talking on hash collisions here). Still, JA3 can be very powerful when used for Threat Hunting and Incident Response.

Hunting for malicious PowerShell using JA3

What is PowerShell being used for

Why hunt for PowerShell? PowerShell is quite popular under adversaries for performing malicious activities. It is also very popular by system admins, but with of course a different end goal in mind. Commonly adversaries use PowerShell for:

  • Downloaders to facilitate the second stage of infection by downloading additional malicious code such as a backdoor.

  • Running backdoors that are written in PowerShell (e.g. PowerShell Empire).

  • Post-exploitation toolkits such as PowerSploit.

System administrators use it for:

  • Automating system administration activities.

  • Far less common, compared to adversaries, for downloading files from the internet.

Why hunt for PowerShell?

The above stated examples of adversary activities performed using PowerShell, which make it very interesting from a security monitoring perspective to know when PowerShell communicates to the internet.

Why use JA3 and what to take into account

Other methods exist besides Invoke-WebRequest for communicating over the internet using PowerShell. I will use this one as an example.

When using the PowerShell cmdlet Invoke-WebRequest for communicating over the internet a User-Agent is sent containing PowerShell: "Mozilla/5.0 (Windows NT; Windows NT 6.3; en-US) WindowsPowerShell/4.0". However, this can easily be changed by providing a custom User-Agent to let the traffic look more normal (-UserAgent "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"). That is why relying solely on the User-Agent is not good enough. Modifying the User-Agent is actively being done by malware.

A far more reliable way of identifying PowerShell that communicates to the internet is to have a look at its JA3 hash values. Yes, we have more than one single JA3 hash for PowerShell:

  • The JA3 hash can differ between PowerShell versions. For example:

    • Windows 7 PowerShell 5.0: 05af1f5ca1b87cc9cc9b25185115607d

    • Windows 7 PowerShell 6.0: 36f7277af969a6947a61ae0b815907a1

  • Differences in Windows versions:

    • Windows Server 2016 PowerShell 5.1: 235a856727c14dba889ddee0a38dd2f2

    • Windows 10 PowerShell 5.1: 54328bd36c14bd82ddaa0c04b25ed9ad

  • There is a way of modifying the TLS version being send in the TLS Client Hello message and thereby having a different JA3 (-SslProtocol parameter in PowerShell v6 for Invoke-WebRequest).

  • When no domain name is involved with setting up the TLS connection, the Server Name Indication (SNI) extension is missing, hence a different JA3 hash.

  • Other methods of communicating to the internet using PowerShell can result in another JA3 hash value (e.g. when Windows BITS is used it can differ depending on the Windows version).

As stated before, there can always be collisions with other client applications which have the same JA3 hash as being used for PowerShell. All should be taken into account when doing proper Threat Hunting.

The hunt

Once we know which JA3 hashes can be seen in your environment, you can start hunting for interesting events. Expect to have collisions and therefore a way of picking out the notable events. A tactic here is to use stacking and look at the bottom of the stacked domain names (i.e. the domain names that occur least frequent). From their pivot to the associated URLs to spot possible malicious traffic. It will also help to enrich the events with the domain registration date and first start with looking at the youngest domain names. And you can add the date of first occurrence for the domain name within your IT Infrastructure to fist check the relative new domain names. Of course, all depends on the capabilities of your tools. Be creative here to see what works best within your environment.

JA3 hunting with Darktrace

Darktrace allows us to perform more advanced hunting with JA3 by employing some very useful metrics. They can be simple like the type of traffic (e.g. HTTPS) and more advanced like the rarity of a domain name within your environment. Metrics are used within Darktrace to build models. A model will have a set of conditions that need to be met before it triggers. In the terms of Darktrace a triggered model is called a model breach.

Hunting hypothesis -> Model

I will explain for one particular JA3 metric within Darktrace how this can be used with the following hunting hypothesis:

An adversary infects a victim's endpoint with a backdoor that starts communicating over HTTPS to a command and control (C2) server by sending beacons on regular or irregular intervals.

For this hypothesis the following characteristics are notable:

  • We hope, and we can somewhat assume, that the backdoor will have JA3 hash which is not frequently seen within our IT infrastructure.

  • Communications to the C2 server's destination are rare within your environment. When not dealing with domain fronting for which the domain is not frequently being accessed by other systems within your environment.

  • The backdoor sends beacons to stay in contact with its C2 server.

You can take the above characteristics to create a model. With this model we combine several weak indicators to increase our chances in detecting C2 channels. The important Darktrace metrics for this model are:

  • "Unusual JA3 hash": for example you can set this to 90% only to look at rare JA3 hashes within your whole environment.

  • "Rare external endpoint": you can do something similar for this metric by only taking into account the rare destinations (IP or domain) within your environment.

  • "Beaconing score": this metric also expects a percentage. The higher the percentage the more regular the beaconing is occurring.

Adversary backdoors often have a configurable jitter to prevent sending a beacon exactly every X minutes. For example, by introducing a variation of 40%. Resulting in the traffic to blend in with normal outgoing network traffic, and thereby harder to detect. Within Darktrace this is one of the factors that will result in a lower "Beaconing score" and therefore still detectable when combined with other metrics.

Happy hunting!