When chatting through the DNS over HTTPS based command and control technique with defenders, something which came up in a blue teams arsenal caught my attention. This was JA3 which is an open source project from Salesforce which has been integrated into a lots of security software and appliances which monitor for malicious network traffic based on the very specific behavior that clients go about making SSL/TLS connections. I set out to investigate the concept and see what can be done from a red team angle to blend in. In summary, I was able to quickly develop a simple proof of concept which implements a HTTP based Inter-Process Communications (IPC) channel between a modern web-browser running some custom JavaScript code and .NET, so that all external traffic was routed via the web browser rather than revealing any traits of the underlying code.

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.” [1]

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.

I wanted something to plug-in to existing DoHC2 code in C# and was not specific to one particular fingerprint or web browser. So I came up with the idea of using a localhost HTTP based IPC channel between .NET and the web browser. I could then write some JavaScript code which does the following:

• 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:

https://github.com/dtmsecurity/3aj-lib

Conclusion

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.

Potential Mitigations

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.

Update

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.