AndroxGh0st and the limits of TLS fingerprinting

May 2026

The same scanner toolkit AWS attributed to Interlock ransomware in March 2026 also runs AndroxGh0st credential theft and two other cybercrime campaigns in CyberDesserts research, showing TLS fingerprints alone cannot reliably identify which threat group is behind an attack.

AWS attributed the fingerprint to Interlock ransomware against Cisco Secure Firewall Management Center in March 2026. The same JA3 hash (fingerprint) appears in CyberDesserts research data producing three additional campaigns: AndroxGh0st credential harvesting on AI infrastructure, AI-tool reconnaissance against vLLM endpoints, and a multi-vector exploit burst across several recent CVEs. One scanner toolkit, four distinct cybercrime operations. IOC libraries treating this hash as operator-specific will misclassify some catches.

Five of 421 unique source IPs in a 120-hour AI infrastructure research deployment produced the same JA3 hash, b885946e72ad51dca6c70abc2f773506. The population frequency of 1.188% is consistent with operator-toolkit-specific fingerprinting rather than commodity library defaults.

The cross-link is novel. Published AndroxGh0st coverage from CISA Joint Advisory AA24-016a, the FBI advisory, and Lacework's original 2022 family disclosure, alongside subsequent vendor research, documents IPs, user agents, and POST body signatures. None of it records a JA3 fingerprint for AndroxGh0st. At the time of writing, the only public source for this hash was AWS's Interlock report, which attributes it to ransomware against Cisco FMC, not to AndroxGh0st. No public source at that point had connected the two operator families through this fingerprint.

Get threat intelligence like this delivered to your inbox. Subscribe to CyberDesserts for practical security insights, no fluff.

Indicators of compromise across the four JA3 campaigns

One JA3 fingerprint b885946e72ad51dca6c70abc2f773506 runs through four cybercrime campaigns in the table below. Three come from CyberDesserts research, one from AWS Security Blog's 18 March 2026 Interlock report. Different IPs. Different user agents. Different post-exploitation behaviour. The fingerprint is the only thing connecting them.

← Scroll to see full table

Source: CyberDesserts research (first three campaigns); AWS Security Blog, 18 March 2026 (Interlock campaign)

AndroxGh0st activity in the research data

Our research deployment ran for approximately 120 hours on infrastructure configured to present as AI services, including a vLLM model server, with supporting application frontends. AWS honeytoken credentials were planted at conventional .env paths to capture downstream validation activity. The deployment is described in detail in the credential pipeline research; this article uses two specific findings from that deployment as the foundation for the JA3 cross-attribution work.

Two IPs from the captured data have HIGH-confidence attribution to the AndroxGh0st operator family through four independent indicators of compromise: the canonical AndroxGh0st POST body (0x[]=androxgh0st) documented in CISA Joint Advisory AA24-016a, an AndroxGh0st-family harvest user-agent rotation pattern, a Boto3 validator user agent matching the documented AndroxGh0st validation toolchain, and honeytoken triggers from credentials harvested by these IPs being used in authenticated AWS API calls within minutes of harvest. The two IPs are 38[.]248[.]95[.]236 and 168[.]222[.]97[.]137, both observed across multiple sessions within the observation window with reproducible enumeration scripts.

Each of these IPs also produced TLS handshakes with the JA3 hash b885946e72ad51dca6c70abc2f773506. That hash is the one AWS published as an Interlock ransomware indicator in March 2026.

The JA3 hash from AWS's Interlock ransomware advisory

The AWS Security Blog post, authored by CJ Moses (CISO of Amazon Integrated Security) on 18 March 2026, documents Interlock's exploitation of CVE-2026-20131 in Cisco Secure Firewall Management Center. The vulnerability was disclosed by Cisco on 4 March 2026. Interlock had been exploiting it since 26 January 2026, 36 days before public disclosure. The campaign fits the broader pattern of ransomware groups targeting firewall and VPN appliances for initial access into enterprise networks.

AWS captured the Interlock activity through Amazon MadPot, its global sensor network. The method mirrors ours: deployments built to attract and record adversary activity, with the resulting indicators published for defenders. What gave AWS unusual depth was an operator mistake. Interlock left a staging server misconfigured, and that single lapse exposed the group's full toolkit, from the remote access trojans and reconnaissance scripts to the evasion tooling and the staged attack chain. The attribution itself came from recovered artefacts matching Interlock's known tradecraft: the ransom note branding, the TOR negotiation portal, and a per-victim tracking identifier carried in each note.

The IOC table published in the AWS post includes two JA3 hashes:

← Scroll to see full table

Source: AWS Security Blog, 18 March 2026

Two JA3 fingerprints in AWS's attribution for the same campaign is itself notable. Interlock's scanner infrastructure has TLS-stack heterogeneity on AWS's side too, with two distinct fingerprints in use across the January and March observation windows. The first hash (b885946e...) appears in both observation windows; the second (f80d3d...) appears only in March. This article is concerned with the first hash, which is the one that matches the AndroxGh0st observations in the research data.

AWS's IOC table also published three exploit source IPs, an HTTP user agent (Firefox 136.0 on Windows), C2 fallback IPs, backend C2 infrastructure, a staging host IP, and operational domains. None of the AWS-published IPs appear in our research deployment's logs at any point during the ~120-hour observation window. The match between the two datasets sits entirely at the TLS fingerprint layer, not at the IP layer.

The JA3 match: AndroxGh0st evidence chain

Of the 421 unique source IPs in the TLS capture, five produced the JA3 hash b885946e72ad51dca6c70abc2f773506, a population frequency of 1.188%.

That figure matters for distinguishing operator-specific scanner tooling from commodity library defaults. A default python-requests or curl configuration produces a JA3 that would appear on 5-20% or more of the IPs in a dataset of this size. A figure of 1.188% across 421 distinct IPs is consistent with operator-toolkit-specific fingerprinting: rare enough that incidental shared use across unrelated operators is implausible, common enough to recur across multiple operator instances using the same tooling. The frequency sits closer to the commodity boundary than initial mid-deployment estimates suggested, and further confirmation against additional datasets would tighten the operator-specificity claim.

Two of the five JA3-matched IPs are the HIGH-confidence AndroxGh0st operators identified earlier. The other three IPs produced the same JA3 doing different work and are addressed in the next section.

For the AndroxGh0st attribution, the honeytoken evidence is the strongest single piece of the chain. The IPs that produced the JA3 handshake on our research deployment also harvested credentials from planted honeytokens, then used those credentials in authenticated AWS API calls under their own source IP. Both stages of the chain are observable.

38[.]248[.]95[.]236 first appeared on the deployment early in the observation window and ran the full AndroxGh0st enumeration script:

• Reconnaissance POST to / with body rand%5EX=_tools
• GET to /.env returning a 200 response containing the planted token
• RCE probe against /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
• Paired GET and POST requests against a wordlist of .env variants, carrying the canonical 0x[]=androxgh0st POST body
• A phpMyAdmin enumeration sequence

Across the same day, this IP produced 50 POSTs containing the AndroxGh0st body signature and 104 GETs against credential-harvesting paths.

The same IP then fired four honeytoken triggers across the same day, each one an authenticated AWS API call using the credentials it had harvested:

← Scroll to see full table

Source: CyberDesserts research deployment, honeytoken trigger logs

Two complete validation cycles, each one consisting of a modern Boto3 + Windows Server 2022 + Python 3.14.5 stack call followed approximately 12 minutes later by a legacy Boto3 1.24.19 + Windows 10 + Python 3.10.6 stack call. The legacy stack is consistent with publicly documented AndroxGh0st validator infrastructure from the original 2022 disclosure window. The pattern is consistent with two-stage backend validation infrastructure: current harvest tooling that performs immediate fresh-credential validation, and a legacy validation pipeline that runs against captured credentials with a roughly 12-minute delay.

The Boto3 strings look like unmodified defaults, not spoofed user agents. The operators rotate harvest traffic across a five-user-agent kit, yet the validation tooling reports its actual Boto3 and Python versions and operating system. Varied at the front door, untouched at the back. That asymmetry is what makes the validator stack a reliable fingerprint.

168[.]222[.]97[.]137 reproduces the pattern. Four honeytoken triggers from this IP across two consecutive days later in the observation window, using the same two Boto3 stacks in the same cycle pattern. Two HIGH-confidence IPs is a small sample for AndroxGh0st attribution; the cross-attribution claim should be read as an initial empirical observation warranting further investigation, not a settled characterisation of the AndroxGh0st operator population. The reproducibility of the toolchain across both IPs and across multiple sessions makes the attribution defensible within those bounds.

This was not a finding I went looking for. Reviewing the AWS Interlock blog post against our research deployment's TLS data was meant to be a routine IOC sweep: check the published indicators, note any matches, move on. The match on b885946e72ad51dca6c70abc2f773506 changed the question from "is there any overlap" to "what does it mean that the JA3 AWS attributes to Interlock is producing AndroxGh0st credential harvesting in our data."

The same JA3 across four campaign types

The other three IPs in our research deployment that produced the same JA3 are not AndroxGh0st. They produced the same TLS fingerprint while doing entirely different things.

107[.]150[.]117[.]121 made eight distinct GET requests against port 8000 (the deployment's vLLM persona) during the observation window. Zero credential-path probes. Zero POSTs with the AndroxGh0st body signature. The path selection included a probe of /update_weights_from_tensor, an endpoint specific to vLLM's distributed training weight synchronisation. The behaviour is AI-tool-specific reconnaissance, not credential harvesting. Same JA3, different operator profile.

45[.]148[.]10[.]249 appeared later in the observation window and issued 212 requests across 155 distinct paths in approximately one second. The path mix combined Spring Cloud Gateway RCE (CVE-2022-22947), Drupalgeddon2 (CVE-2018-7600), WordPress Breeze SSRF, path-traversal credential disclosure, and multi-framework .env enumeration. Fifty of the requests touched credential-harvesting paths but none used the canonical AndroxGh0st POST body. The behaviour is a multi-vector exploit burst throwing several recent CVEs at any responding service. Same JA3, again different operator profile.

95[.]153[.]32[.]118 made a single GET request against port 8443 early in the observation window. The path was a credential-harvesting target but the IP produced no canonical AndroxGh0st POST body, no Boto3 validation, and no further activity. A lighter probe of unclear archetype, possibly reconnaissance from an operator deciding whether to invest in the target. JA3-only attribution; insufficient behavioural evidence to place it cleanly in any archetype.

The attribution chain across all four observed use cases of the JA3 (three operator types in this research data plus AWS's Interlock attribution) is summarised below:

← Scroll to see full table

Source: CyberDesserts research (first three rows); AWS Security Blog, 18 March 2026 (Interlock)

Four distinct campaign types. One shared scanner-toolkit fingerprint. Different HTTP user agents, different IP infrastructure, different post-exploitation behaviour, different campaign objectives, different victim ecosystems. The fingerprint that connects them sits at the TLS scanner-toolkit layer; everything observable above that layer varies.

The interpretation that best fits the evidence is a shared scanner toolkit, not shared operator infrastructure. Two operator groups running the same toolkit produce identical JA3s without sharing IPs. One group reusing its own infrastructure across both campaigns would typically show IP overlap. None exists between the AWS-published Interlock IPs and the JA3-matched IPs in the research data, which points to a shared toolkit rather than shared infrastructure.

How that toolkit is shared is open: sale or trade in cybercrime forums, a common open-source base, or licensing across operator groups are all plausible. Shared infrastructure across distinct campaigns remains possible, if less likely, and the data cannot conclusively separate the two. Whichever framing holds, the defender consequence is the same.

What the JA3 cross-attribution means for defenders

A JA3-based detection catch on b885946e72ad51dca6c70abc2f773506 cannot tell the defender which downstream behaviour to expect. The same hash matching at the edge could indicate AndroxGh0st-style credential harvesting (most likely volume-wise in the observed data), AI-tool-specific reconnaissance, a multi-vector exploit burst, or in rare cases a precursor to Interlock ransomware operations. The hash narrows the candidate behaviours but does not select one. The IOC table in the first section is the practical artefact for the triage step: a JA3 catch should trigger behaviour-classification against the observable HTTP user agent, request path mix, and POST body content before the response plays out.

Response differs by campaign type. Credential rotation makes sense for AndroxGh0st-attributable activity; perimeter hardening makes sense for the exploit-burst archetype; immediate firewall management isolation makes sense if the activity is Interlock-attributable. Reactive playbooks tied to a single JA3 will respond to the wrong threat in some non-trivial fraction of catches.

For AI infrastructure operators, the cross-attribution adds context without changing the odds: the same scanner toolkit appears in ransomware operations elsewhere, but the volume-weighted likelihood is that any given catch is still credential harvesting, not a ransomware precursor. The practical consequence is for IOC libraries. b885946e72ad51dca6c70abc2f773506 should be tracked as a scanner-toolkit indicator with multiple known campaign associations, not as an AndroxGh0st-specific or Interlock-specific signature, the same way dual-use attacker tools resist mapping to a single operator.

The novelty bears restating. Published AndroxGh0st coverage documents IPs, user agents, and POST body signatures but no JA3 fingerprint, and AWS publishes this JA3 only in the Interlock ransomware context. This research is the first to link the AWS-attributed Interlock JA3 to the AndroxGh0st operator family.

JA3 fingerprinting has known evasion mechanisms. Operators aware of JA3-based detection can rotate cipher suite ordering, change TLS library versions, or alter handshake parameters in ways that produce a different hash. The fingerprint documented in this research should be treated as a current detection signature that may shift over time as the underlying toolkit evolves.

The cross-attribution claim is bounded. The underlying scanner toolkit is shared between distinct campaign types, with no further inference about whether operator groups overlap. This article does not claim that AndroxGh0st operators are Interlock operators, or vice versa. Whether this JA3 remains a stable scanner-toolkit fingerprint over time, whether the campaign-type breadth on it grows or contracts, and whether further cross-attributions emerge between separately-attributed operator families remain open questions for further investigation. The fingerprint sits at the scanner-toolkit layer. The operator layer above it varies.

This article is one piece in an ongoing programme of research on AI infrastructure scanning, the operator population that targets it, and the defender implications of what's observable. Related pieces in this programme: the AI infrastructure scanning research that started the programme and the credential pipeline research on harvest-to-validation timing.

CyberDesserts publishes original threat research and practitioner analysis. Subscribers get new findings as they land, plus weekly practical security content. No sales pitches, no fluff.