Successful login correlated with suspicious JA4/JA3 TLS fingerprint

title: Successful login correlated with suspicious JA4/JA3 TLS fingerprint
id: 0c71d42b-d918-4698-a849-d5d5ee5b208b
status: experimental
description: |
    Detects if there are successful logins from JA3 or JA4 signatures seen in credential stuffing patterns.
    This is a strong indication that the respective accounts have been compromised.
author: Okta
date: 2025-10-16
modified: 2025-10-16
references:
    - https://auth0.com/docs/secure/attack-protection/view-attack-protection-events
logsource:
    product: auth0
detection:
    selection:
        data.type:
            - s # Successful login
            - scoa # Successful cross-origin authentication
    condition: selection
explanation: >
    This detection is designed to identify potential account compromise by correlating successful logins
    with the TLS fingerprint (JA4 hash) seen in recent failed attempts and requests alerted by attacked protection features.
    The Splunk query first identifies suspicious JA4 hashes by looking for IPs that generated high number of failed logins
    or attack protection events.
    Thereafter, it filters successful events (s and scoa), retaining only those that share a JA4 hash with the previously
    identified suspicious traffic.
    The final output lists the successful login, the suspicious hash, and the username,
    providing a high-fidelity indicator that an account was successfully breached using the same automated attack tool
    or infrastructure responsible for the failed attempts.

    The Sigma detection block is used only to identify the successful login events.
    The query generated by Sigma CLI, should be extended with listing JA3/JA4 fingerprints, e.g. `| table data.user_name data.security_context.ja4` in Splunk.
    Thereafter, these can be manually compared to suspicious fingerprints returned by the credential_stuffing_signals.yml detection.
    Additional steps for Sigma rule are needed due to limitations of the Sigma language, while the splunk block already implements all this correlation.
splunk: |
    index=auth0 data.tenant_name="{your-tenant-name}"
    | bin _time span=1h
    ``` Successful login events and associated JA4 ```
    | search data.type IN (s, scoa)
    | rename data.security_context.ja4 as seen_ja4_hash
    | fields _time, data.type, seen_ja4_hash, data.user_name
    ``` Filter these events using the list of JA4 hashes seen in failed events pointing to credential stuffing ```
    | join type=inner seen_ja4_hash [
        search index=auth0 data.type IN (f, fu, fp, pwd_leak, limit_wc, limit_sul, limit_mu, fcoa)
        | stats count as cnt_events_per_ip by data.security_context.ja4 data.ip
        | where cnt_events_per_ip > {threshold_events_per_ip}
        | fields data.security_context.ja4
        | rename data.security_context.ja4 as seen_ja4_hash
    ]
    ```Final output ```
    | table data.type, seen_ja4_hash, data.user_name
comments:
    - The Splunk query above shall be tuned to reflect a valid tenant name,
      and a threshold for number of events per IP, i.e. {threshold_events_per_ip}.
    - The detection can be adjusted to monitor the attack protection feature in use.
    - Failed login events (f, fu, fp, fcoa) can be considered separately from Attack protection events
     (pwd_leak, limit_wc, limit_sul, limit_mu).
    - Other patterns indicating credential stuffing attack can be plugged in in this query.
      See three signals from the detection credential_stuffing_signals.yml.
    - As an alternative to JA4, a JA3 fingerprint can be used for correlation.
     Note, that JA4 are more stable and less sensitive to small changes to violitily of TLS handshake details.
    - Filter out JA4 fingerprints from known browsers/applications/tools https://ja4db.com/
tenant_logs: |
    type: (s scoa)
prevention:
    - Block or monitor the traffic from suspicious JA4/JA3 with the Network ACL feature.
    - Initiate password reset for identified accounts.
    - General preventions applied to credential stuffing listed in credential_stuffing_signals.yml.
falsepositives:
    - JA3/JA4 might be attributed to legitimate traffic. This can happen when selected {threshold_events_per_ip} is too low and reacts on legitimate failed events.
level: medium
tags:
    - attack.credential-access
    - attack.t1110.004