What is JA3?
“JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.” 
JA3 hashes enable a network sensor or device to identify client applications as they have unique traits in the way they go about SSL/TLS. The JA3 hashes can be a contributing factor in supporting security analysts and their tooling to decide what ‘normal’ looks like on the network. In some cases, when malware uses their own communications code, it can help identify known bad and in other cases it may be used to decide what is known good or is benign i.e. a commonly used web browser.
How can attackers bypass or trick JA3?
In short, an attacker needs to make sure that any outbound secure communications exhibits the same behavior as software which is normally observed to be sending traffic out to the Internet. There a number of factors which contribute to the generation of a JA3 hash which would all have to be met. Alternatively, an attacker can use the software directly. This can be achieved by, for example, using a COM object or API.
- Observe a queue of requests via IPC.
- Makes a request using jQuery’s getJSON() hence the outbound traffic is sent via the web browser, hence analysis of traffic would show the browser’s JA3 hash.
- Sends the result back via IPC.
I have released a library called aptly named '3ajlib' and test client which does DNS over HTTPS resolution via this mechanism. This could quite easily be modified to make more arbitrary web requests with the only caveat that the same origin policy needs to considered. The endpoint would need to explicitly allow the HTML page on localhost access.
The proof of concept project is available here:
This can probably be potentially seen as solving a problem that did not exist since the JA3 hash of most standard .NET web clients is used frequently observed in other benign things. That said, on the flip side if a known web browser is seen as a less risky thing to be talking outbound then this might be an interesting concept. This is probably a similar situation to having a malicious web browser extension.
Whilst the outbound traffic from the web browser may look slightly more legitimate in this scenario this potentially introduces some red flags and hardening considerations.
- Looking for new HTTP listeners being created on a system and any related logs.
C:\Users\dtm>netsh http show servicestate Snapshot of HTTP service state (Server Session View): ----------------------------------------------------- --snip-- Server session ID: FF00000520000162 Version: 2.0 State: Active Properties: Max bandwidth: 4294967295 Timeouts: Entity body timeout (secs): 120 Drain entity body timeout (secs): 120 Request queue timeout (secs): 120 Idle connection timeout (secs): 120 Header wait timeout (secs): 120 Minimum send rate (bytes/sec): 150 URL groups: URL group ID: FD0000004000001F State: Active Request queue name: Request queue is unnamed. Properties: Max bandwidth: inherited Max connections: inherited Timeouts: Timeout values inherited Number of registered URLs: 1 Registered URLs: HTTP://LOCALHOST:8666/3AJ/ --snip--
- It may be possible to apply a 'urlacl' to prevent low-privileged users from creating a localhost HTTP listener.
- An attacker would have to launch the web browser to point to the local web server. This process creation may look suspicious itself.
Literally when posting this on Twitter I saw this awesome blog post from MDSec in my feed. This adopts a different approach of using an IE COM object for similar reasons. Nice work https://twitter.com/0x09AL! Check this out.