When “AES-GCM” Becomes a Browser-Reversing Invitation

Browser Telemetry, Obfuscated JavaScript, and a Client-Side Secret That Wasn’t Secret

While reviewing browser traffic, I noticed an encrypted telemetry beacon being sent at regular intervals from a heavily obfuscated client-side JavaScript file.

That alone is not unusual. Large web platforms commonly collect browser, device, timing, and behavior signals for fraud detection, bot mitigation, abuse prevention, and general risk scoring.

What made this interesting was the cryptographic design.

The telemetry was protected with AES-GCM, but the symmetric key required to decrypt and authenticate the payload was shipped directly to the browser inside the JavaScript bundle.

That creates an important distinction:

AES-GCM was not broken.
The trust model around AES-GCM was broken.

If the client receives the symmetric key, the client can decrypt telemetry, modify plaintext, and generate new ciphertext with a valid authentication tag. At that point, AES-GCM still works exactly as designed, but it no longer proves that the data came from a trusted source.

It only proves that the data came from someone who had the key.

And in this case, every browser had the key.

Context

This write-up summarizes a responsible disclosure report involving client-side telemetry, obfuscated JavaScript, and authenticated encryption used in a way that weakened the integrity claims of the telemetry pipeline. While the full-scope of the security implication is unknown, what I do know for certain is that I was able to successfully decrypt the data consistently across session, and forge bogus data to send to the server. After analyzing the decrypted payload for quite some time trying to figure out what it was doing, after searching some of the variable patterns and matrix values it became evident that it was indeed a large matrix of various data points gathered from your client browser whilst on the site etc. I’d like to note that in most cases I would’ve fully fuzzed the server with different payloads for the cookie or just tweaking various parameters to try to invoke further unintended behavior. The reason I didn’t in this case is because it’s my assumption that most telemetry data on a site/retailer of that site is being saved directly to a Machine Learning dataset database. In other words, this hardcoded key would allow for a malicious actor to spam bogus data using the AES Key + Auth tag found after de-obfuscating the JavaScript. This is a very very easy fix via the use of Hybrid Public Key Cryptography and an ephemeral key-exchange of some sort with additional trust anchors and integrity checks in place.

The report was ultimately closed as informative. While I had hoped that the triager would be able to give me some more insight, It’s not my place to ask and from the sounds of it he wasn’t able to come to a clear conclusion either. I don’t know how there backend works, I was actively probing the server whatsoever, this was found on accident after I fat-fingered the wrong button on my keyboard (one of the ($F_{n}$) keys.

I disagree with some parts of the triage reasoning, but the final classification is understandable if the telemetry was treated as low-trust advisory data rather than as an authoritative security decision input. Though I question this because regardless, the server is accepting untrusted data being input, and given how quick/easy it was to find that security issue; it’s a very reasonable assumption to say that there is likely more vulnerabilities or “Oracles” of information in regards to the servers in question and the role they played within there cloud network topology.

That distinction matters.

This was not demonstrated as:

  • account takeover,
  • authentication bypass,
  • payment fraud,
  • MFA bypass,
  • server-side authorization bypass,
  • or confirmed production bot-detection bypass.

What was demonstrated was narrower but still technically meaningful:

  • client-side exposure of a symmetric AES-GCM key,
  • decryption of encrypted telemetry,
  • local mutation of telemetry fields,
  • re-encryption with a valid AES-GCM authentication tag,
  • and proof that the cryptographic authenticity boundary was client-controllable.

That may or may not translate into direct business impact depending on how the telemetry is consumed server-side.

The cryptographic issue is real. The exploitable impact depends on the downstream trust model.

Discovery

During traffic inspection, I observed a telemetry endpoint receiving opaque encrypted payloads at regular intervals.

The JavaScript responsible for producing those beacons was delivered once near the start of the browser session and appeared to be associated with anti-bot, behavioral, or risk-scoring telemetry.

The relevant script was heavily obfuscated.

The pattern was familiar:

  • large string table,
  • lookup resolver function,
  • rotating array,
  • runtime checksum stabilization,
  • indirect string references,
  • and dense calls resembling _0x...(...) throughout the code.

In other words, standard JavaScript obfuscation rather than a meaningful security boundary.

After deobfuscation and cleanup, several important strings and configuration values became readable, including route fragments, telemetry identifiers, and AES-GCM-related configuration.

The Key Finding

Inside the decoded configuration was a client-side value used as the AES-GCM key material.

For the public version of this write-up, the exact value is redacted:

{
  kd: "[REDACTED_CLIENT_SIDE_AES_KEY_MATERIAL]",
  tkd: "[REDACTED_TOKEN_OR_KEY_IDENTIFIER]",
  it: "[REDACTED_TELEMETRY_INSTANCE_ID]"
}

The important issue is not the specific value. The issue is that the browser received the symmetric key at all.

In a symmetric encryption scheme, the same key is used to encrypt and decrypt. With AES-GCM, that same key is also used to authenticate the ciphertext.

So if the key is exposed to the client, the client can do more than read the telemetry.

The client can produce new telemetry that passes AES-GCM authentication.

“But It Uses AES-GCM”

AES-GCM is an authenticated encryption mode. Used correctly, it provides confidentiality and integrity for encrypted messages.

The issue here is not AES-GCM.

The issue is key custody.

A simple way to frame it:

Authenticated encryption proves that someone with the key created the message.

That property is useful only if possession of the key meaningfully identifies a trusted party.

If the key is embedded in JavaScript and sent to every browser, then possession of the key identifies almost nothing. Any user, researcher, bot operator, scraper, or attacker who receives the JavaScript can recover the key and generate valid ciphertext.

That means the server cannot treat successful AES-GCM authentication as proof that the telemetry is honest, unmodified, or generated by an uncompromised client.

At best, the encryption prevents passive observers from casually reading the telemetry in transit.

It does not establish client integrity.

What Decryption Revealed

After recovering the key material and reconstructing the payload format, I was able to decrypt captured telemetry locally.

The decrypted structure contained several top-level sections that appeared to represent browser state, device characteristics, behavioral signals, timing data, and related telemetry.

Examples of observed telemetry categories included:

  • browser fingerprint data,
  • WebGL renderer information,
  • font and plugin metadata,
  • timing and event data,
  • storage capability checks,
  • hardware capability data,
  • permission-state probes,
  • timezone and locale information,
  • behavioral interaction signals,
  • and browser/environment consistency checks.

Some permission probes appeared to reference sensitive browser capabilities such as camera, microphone, clipboard access, geolocation, display capture, persistent storage, and window-management-related APIs.

That does not necessarily mean those permissions were granted or abused. Permission probing is common in fingerprinting and anti-bot systems. But it does show that the decrypted payload was not meaningless filler. It contained real telemetry that could plausibly feed a risk or fraud decision pipeline.

Local Forgery Proof

To stay within responsible research boundaries, I did not attempt production fraud, account abuse, payment abuse, or malicious bot evasion.

Instead, I built a local-only proof of concept to validate the cryptographic property in isolation.

The local harness performed the following steps:

Captured telemetry beacon
        ↓
Extract IV / ciphertext / tag
        ↓
Decrypt locally
        ↓
Parse plaintext telemetry
        ↓
Modify benign fields
        ↓
Re-encrypt with AES-GCM
        ↓
Verify the new authentication tag locally

The result was straightforward:

A party with the client-side key can create modified telemetry with a valid AES-GCM tag.

That is exactly what authenticated encryption allows when the party has the key.

The question is not whether this is cryptographically valid. It is.

The real question is whether the backend gives this telemetry enough trust for forgery to matter.

Impact Analysis

The likely severity depends heavily on server-side architecture.

If the telemetry is treated only as advisory, low-trust, one-signal-among-many risk data, then the practical impact may be limited. In that model, forged telemetry might be noisy, ignored, cross-checked, or weighted lightly against stronger server-side signals.

If, however, the telemetry materially influences bot detection, fraud scoring, session trust, abuse prevention, or automation controls, then client-side key exposure becomes more serious.

Potential security implications could include:

  • manipulation of browser or device fingerprint metadata,
  • suppression or alteration of automation-detection signals,
  • spoofing of environmental characteristics,
  • replay or mutation of telemetry structures,
  • weakening of anti-bot integrity assumptions,
  • and degradation of fraud or abuse scoring quality.

A reasonable conservative framing is:

The vulnerability compromises the authenticity of encrypted client telemetry.
The business impact depends on how much the server trusts that telemetry.

That framing is stronger, cleaner, and more defensible than claiming confirmed fraud bypass without proving it.

CWE Mapping

The cleanest primary weakness is:

  • CWE-321: Use of Hard-coded Cryptographic Key

Related mappings may apply depending on implementation details:

  • CWE-798: Use of Hard-coded Credentials — if the key functions as a credential or trust-bearing secret.
  • CWE-345: Insufficient Verification of Data Authenticity — if backend systems rely on this telemetry as authentic client state.
  • CWE-311: Missing Encryption of Sensitive Data — weaker fit; the data is encrypted, but confidentiality is undermined if the decryption key is available to every client.

I would avoid leading with CWE-311 unless the argument is carefully framed. The stronger claim is not “there is no encryption.” The stronger claim is “the encryption does not protect against the party it appears designed to constrain.”

Suggested Severity Framing

A defensible severity range would be informative to medium, depending on evidence of downstream trust.

If no backend security decision can be shown to depend on the telemetry, then informative is predictable.

If telemetry manipulation can be shown to alter bot scoring, fraud controls, rate limits, checkout friction, login friction, or abuse-detection outcomes, then the issue becomes meaningfully stronger.

A more careful report summary would be:

Client-side JavaScript exposes AES-GCM key material used to encrypt and authenticate browser telemetry. Because this key is distributed to every client, any client can decrypt, modify, and re-encrypt telemetry with a valid authentication tag. This breaks authenticity assumptions for the telemetry channel. Impact depends on whether backend systems rely on this telemetry for bot detection, fraud scoring, abuse prevention, or session-risk decisions.

That wording is hard to dismiss because it does not overclaim.

It says exactly what was proven and exactly what still needs confirmation.

Why the Report Was Probably Closed

The report was closed as informative because the demonstrated issue stopped at cryptographic controllability.

The proof showed that telemetry could be decrypted and locally re-authenticated after mutation.

It did not conclusively show that this led to:

  • successful bot evasion,
  • reduced fraud scoring,
  • bypassed security friction,
  • unauthorized access,
  • account compromise,
  • payment abuse,
  • or a measurable server-side trust change.

That distinction is frustrating, but it is important.

Security programs usually pay for demonstrated impact, not architectural discomfort.

And in bug bounty, “this design is questionable” is not the same as “this design creates exploitable impact.”

That said, triage should still understand the cryptographic distinction. Calling AES-GCM “encoding” or treating client-side key exposure as harmless because “the server validates it” misses the core issue.

The server may validate the AES-GCM tag, but a valid tag only proves possession of the key.

If every client has the key, that validation does not prove the telemetry is trustworthy.

What I Would Test Next

The useful question is:

What telemetry fields actually influence server-side decisions?

Safe follow-up research could include:

  • differential telemetry analysis,
  • replay consistency testing,
  • schema mutation in a controlled environment,
  • entropy-field sensitivity analysis,
  • browser coherence modeling,
  • comparison of accepted versus rejected telemetry shapes,
  • correlation between telemetry changes and visible security friction,
  • and determining whether risk outcomes change when specific signals are altered.

The goal would be to prove or disprove downstream impact without crossing into fraud, unauthorized access, or abusive automation.

Lessons Learned

1. Obfuscation Is Not a Security Boundary

Obfuscation slows down analysis. It does not prevent analysis.

If a secret is shipped to the browser, obfuscation only changes how long it takes someone to recover it.

2. Client-Side Secrets Are Not Secrets

If JavaScript needs a secret to run in the browser, the user can recover that secret.

No amount of minification, packing, string rotation, or control-flow flattening changes that.

3. AES-GCM Does Not Create Trust by Itself

AES-GCM can authenticate ciphertext, but it cannot decide whether the key holder is trustworthy.

If every client has the key, every client can produce authenticated ciphertext.

4. Weird Crypto Is Not Automatically a Bounty

Cryptographic misuse is worth investigating, but bounty impact usually requires proving a security outcome.

A better mental model is:

Crypto flaw + demonstrated trust boundary failure = stronger report.
Crypto flaw without downstream impact = likely informative.

5. Anti-Bot Telemetry Is a Trust Model Problem

Modern anti-bot systems do not simply ask, “Is this a real browser?”

They ask whether the browser’s environment, behavior, timing, rendering, permissions, storage, network traits, and interaction patterns are coherent enough to look trustworthy.

That makes telemetry integrity important.

But it also means any single signal may be only one small part of a much larger model.

Final Thoughts

This was a valuable research rabbit hole because it exposed a common misconception that is significantly more common than one may think:

Encryption does not automatically mean trustworthy confidentiality.

AES-GCM is a strong primitive, but strong primitives do not save weak key management and misuse of cryptographic primitives.

If a platform sends the AES-GCM key to every browser, then the platform should assume every browser can decrypt, modify, and re-authenticate that telemetry.

Whether that is a vulnerability or just poor architecture depends on what the backend does with the data.

That is the part worth proving.

Still, the core lesson is simple:

If your AES key ships to every browser,
it is not a secret.

References