A sophisticated network breach usually conjures images of complex zero-day chains, state-sponsored spear-phishing, or grueling ransomware deployment. But in the real world of offensive security and enterprise defense, some of the most devastating entry points don’t require writing a single line of exploit code. Instead, they require human curiosity, a public bug tracker, and a single operational oversight.
As the CTO of Unixi, my daily focus revolves around eradicating credential theft and eliminating the massive blind spots in enterprise Identity and Access Management (IAM). Yet, a recent discovery reminded me that sometimes the most glaring identity vulnerabilities aren’t hidden deep inside a company’s network, they are sitting in plain sight on public forums.
This is the story of how a deep dive into a standard Google Chromium bug unexpectedly granted access to the internal identity stack of a massive Fortune 50 enterprise (which we will call MegaRetail Corp), and what happened when we pitted today’s frontier AI models against the exact same data.
1. The Starting Point: An Innocent Bug Report
The journey began not on a dark web forum, but on the public Google Chromium issue tracker. While auditing open issues related to browser stability and enterprise environments, I stumbled upon a high-priority bug report regarding widespread browser rendering crashes affecting thousands of endpoints across a massive corporate fleet.
The ticket was opened by a senior infrastructure engineer at MegaRetail Corp. According to the report, thousands of their corporate machines were experiencing abrupt crashes across their internal infrastructure whenever users interacted with specific web components.
To help the Chromium developers diagnose the root cause, the senior engineer did what any diligent developer would do: they attached Chrome’s official network log (net-internals export) capturing the session right as the crash occurred.
2. The Illusion of Data Masking
When uploading logs to public trackers, enterprise engineers generally rely on automated sanitization. In this case, Google Chrome’s built-in uploading and reporting mechanism did exactly what it was programmed to do: it detected and stripped out standard Cookie headers and Authorization: Bearer tokens to prevent session hijacking.
But this exposes the massive automated data masking limitations of standard tools, they only protect you from known patterns
Curious to see if the crash was reproducible, I downloaded the publicly available network trace. Upon opening the file, it became immediately clear that the file was massive, containing hundreds of thousands of raw HTTP requests and responses. While the standard Cookie fields were safely blanked out, the raw custom headers remained completely untouched.
3. Finding the Needle: The ” eyJ” Search Hack
Sifting through millions of lines of unstructured network data manually is an exercise in futility. I knew that if a session token had leaked, it would likely be formatted as a JSON Web Token (JWT).
JWTs famously begin with the base64-encoded string eyJ (which decodes to {“a, the start of the standard {“alg”:…} header). However, running a global search for eyJ inside a massive network packet trace yields millions of false positives because that specific sequence of characters appears naturally in compressed data, images, and random strings.
To bypass the noise, I applied a simple lateral thinking trick. I modified the search query to include a leading space:
” eyJ”
This tiny adjustment isolated instances where eyJ appeared at the very beginning of an HTTP header value rather than inside a random block of data.
The results plummeted from millions to a manageable handful. And right there, buried in an outbound request to an internet-exposed corporate gateway, was the jackpot. The application was passing an unmasked session token through a custom HTTP header named x-session. This is a prime example of why extracting JWT from network logs is a goldmine for attackers
HTTP
POST /identity/v1/authorize HTTP/1.1 Host: auth.global-enterprise.megaretail.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)... x-session: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik1Mcy5F...
4. Dissecting the Spoils
By taking the leaked string from the x-session header and dropping it into a JWT decoder, the entire internal corporate identity structure of the employee was laid bare:
JSON
{
"sub": "emp_98734",
"iss": "https://auth.global-enterprise.megaretail.com",
"iat": 1717416000,
"exp": 1717452000,
"kid": "AUTH.PROD.KEY.V1",
"auth_level": 1,
"assurance_level": "standard",
"profile_type": "standard_user",
"session_id": "aa11bb22-cc33-dd44-ee55-66ff77aa88bb",
"amr": [
"pwd"
],
"jti": "abc123xyz789tokenidentifier4567890abcdef1234567890abcdef",
"email": "jane.doe@example.com",
"samAccountName": "jdoe",
"directory_source": "active_directory",
"network_location": "external",
"distinguished_name": "CN=Jane Doe,OU=Standard Employees,OU=Staff,DC=internal,DC=example,DC=com"
}
The Security Impact
This wasn’t just an expired artifact. The token was active, completely valid, and unexpired. Because the endpoint auth.global-enterprise.megaretail.com was hosted on the public internet to allow remote workers to authenticate, possessing this token meant:
- Full Access to All Applications Behind the Employee’s SSO: Immediate, unfettered access to the employee’s Single Sign-On (SSO) portal. By hijacking this active session, an attacker bypassed perimeter security entirely, gaining direct entry into all internal corporate applications and cloud services assigned to that employee without triggering step-up multi-factor authentication (MFA).
- Internal Reconnaissance: The dgn field mapped out MegaRetail’s internal Active Directory domain controller architecture (DC=corp,DC=megaretail,DC=com), providing an attacker with the exact organizational units (OU=Employees) needed for internal lateral movement.
- Targeted Phishing/Social Engineering: Direct access to internal system IDs (sub) and specific operational parameters, allowing for highly targeted downstream attacks.
5. The Silent Remediation
Practicing responsible disclosure, I immediately drafted a concise email outlining the leak, complete with the specific URL of the public Chromium bug tracker. Then, I sent it directly to the senior engineer who uploaded the file (whose email I obtained from the JWT token).
The reaction was swift, yet completely silent.
Within a short window, the public attachment was deleted from the Chromium ticket. However, my subsequent follow-up emails were entirely ignored. In corporate security, this silence is a known phenomenon. When a high-ranking internal engineer commits a severe operational security violation, the instinct is often self-preservation, silently patching the leak and avoiding any paper trail that could lead to disciplinary action or job loss.
While the bug was successfully remediated, the interaction highlighted a glaring truth: fear-driven security cultures stifle open communication.
6. Man vs. Machine: Why AI Missed the Leak
Shortly after the incident, a fascinating question came to mind: If today’s frontier AI models are marketed as autonomous tools for vulnerability detection and log analysis, how would they perform here?
I spun up several leading frontier Large Language Models (LLMs) via their APIs, ensuring they had large enough context windows to ingest the file. I uploaded the raw, un-sanitized log snippet and provided a direct, clear prompt:
“Analyze this network log file. Identify and extract any leaked credentials, API keys, active session states, or severe security vulnerabilities.”
The result? Total failure across the board. Every single model analyzed the log, gave a high-level summary of the network traffic, noted the browser crash mechanics, and responded with a list of low severity token leakages, leaving the most sensitive key out.
Why did the AI fail where a human succeeded?
- The Context Sea: Large log files introduce vast amounts of noise. The LLM patterns prioritized the dominant syntax of the file (the crash diagnostics and HTTP routing data), causing the single string hidden inside a custom header to become mathematically diluted within the context window.
- Strict Pattern Matching: AI models are heavily trained to look for explicit, highly documented security anti-patterns (e.g., Authorization: Bearer, AWS_SECRET_ACCESS_KEY, password=). They lack the “lateral intuition” to recognize that a custom header like x-session combined with an obscure base64 string starting with a space and eyJ constitutes a critical exposure.
Conclusion & The Unixi Perspective
This finding highlights a critical lesson for modern enterprise defense. Automated data-masking utilities are excellent at blocking yesterday’s known vectors. However, they cannot anticipate the custom configurations of your internal development teams. If your organization permits engineers to upload raw diagnostic data to public open-source trackers, your perimeter is eventually going to leak.
At Unixi, this is exactly the paradigm we are working to change. The traditional identity stack relies entirely on complex, brittle secrets, tokens, cookies, and headers – passed back and forth across browsers and networks. When a single human error or an unmanaged custom header can expose an entire enterprise identity infrastructure, the architecture itself is flawed.
