**Google** and **Microsoft** have recently delisted **ModHeader**, a popular HTTP header-editing extension, from their respective web stores. This action follows a discovery by **Stripe OLT**, a UK security firm, which identified a hidden browsing-history collector embedded within the extension's official store version. ### Dormant Threat, Real Concern The analysis by **Stripe OLT** revealed that the collector, though present in the genuine extension, was dormant due to an empty allow-list. There is currently no evidence that it ever actively gathered or transmitted browsing domains. The firm's review focused on the **Chrome** build, which accounted for approximately 900,000 users, with an additional 700,000 users on **Edge**. **Microsoft** removed the **Edge** listing on July 3rd, followed by **Google** removing the **Chrome** version a week later, on July 10th. ### How the Collector Worked Version **7.0.18** of **ModHeader** (extension ID `idgpnmonknjnojddfkpgkljpfnnfcklj`) contained a minified background code with a secondary system. Upon first run, this system would create a device fingerprint and load a hardcoded encryption key. As users browsed, it would capture the domain from each opened page, encrypt it, and store it locally, capable of retaining up to 1000 distinct domains. A daily scheduler was designed to bundle the encrypted list with the device fingerprint and transmit it to `api.stanfordstudies[.]com`, subsequently wiping the local copy. The upload time was offset per install to prevent simultaneous beaconing. Independent teardowns by **HackIndex** (on version **7.0.18**) and researcher **Yunus Aydin** (on **7.0.17**) corroborated this data pipeline. Crucially, the collector would only activate if the user's browser matched an entry on an internal allow-list. This list, however, shipped empty, preventing any data collection. A simple update, requiring no new permissions or user interaction, could have populated this list, activating the pre-existing logic for encryption, endpoint communication, scheduling, and storage. ### Active Pings and Plaintext Data While the browsing history collector remained dormant, other aspects of the extension were active. Upon installation, updates, and uninstallation, the extension would ping `extensions-hub[.]com` with product, version, and browser details. Furthermore, a script running on every page was found to be logging real request metadata to local storage in plaintext, indicating active, unencrypted data collection in some capacity. ### Evading Automated Detection Automated security checkers consistently rated **ModHeader** as low risk, with some scores as high as 95 out of 100. This evasion was attributed to several design elements: * **Encryption:** Data was encrypted, making it appear as ciphertext to scanners. * **Gated Uploads:** The upload mechanism was conditional, preventing sandboxes from detecting data exfiltration. * **Code Obfuscation:** Malicious code was minified within a legitimate codebase. * **Reputation:** Endpoints had no prior malicious reputation, and the signed, popular extension appeared trustworthy. A store signature only verifies the source, not the function, of an application. ### Tracing the Infrastructure **Stripe OLT** linked the identified domains to active infrastructure. `stanfordstudies[.]com` has no affiliation with **Stanford University**; it is a repurposed domain fronting an **OpenSearch** backend. `extensions-hub[.]com` is configured for advertising purposes. Both API endpoints resolved to the same **Amazon** server during the analysis, suggesting a single operator. Weak signals, such as a Simplified Chinese locale, a Chinese character for 'salt' (盐), and a China-origin mail provider, loosely point towards a Chinese-speaking operator, though no specific group has been named by the researchers. ### Precursors and Broader Implications Early warning signs for **ModHeader** included user complaints in 2023 regarding ad injection into search results, around the time the extension reportedly became ad-supported. The identity of the party who acquired and modified the extension remains unconfirmed, and researchers have not made claims about the original author. **ModHeader**'s own website still advertises an ad-supported plan that claims no user data collection, a statement difficult to reconcile with the presence of a browsing-history collector. This incident echoes a pattern observed by **Brian Krebs** in 2021, where popular extensions are quietly acquired and repurposed into data exfiltration tools. Recent examples this year include **Chrome** extensions caught collecting data under an "anonymous analytics" label, and another set impersonating **Workday** and **NetSuite** to steal session cookies. Extensions that manage headers or cookies require broad permissions, making them high-impact targets when trust is compromised. ### Recommendations for Users and Defenders **For Users:** * **Remove ModHeader:** Immediately uninstall **ModHeader** from both **Chrome** and **Edge**. Your browser may have already disabled it. Ensure that profile sync or managed extension policies do not reinstall it. * **Rotate Secrets:** If you have ever pasted sensitive information (e.g., API keys, bearer tokens, session cookies) into **ModHeader**, rotate these credentials. Researchers found its header-history feature stored full HTTP headers on disk. **For Defenders:** * **Block Endpoints:** Block and log `stanfordstudies[.]com` and `extensions-hub[.]com` at the DNS and proxy levels. * **Search Logs:** Search your logs for the extension ID (`idgpnmonknjnojddfkpgkljpfnnfcklj`) and any POST requests to `api.stanfordstudies[.]com/app/log`. **Stripe OLT** has published ready-to-run **KQL** hunting queries for **Microsoft Defender** and **Sentinel**. This incident highlights a critical vulnerability in the extension ecosystem: the existence of a complete, store-verified data collector within a trusted tool, designed to be activated by a routine update. The fact that automated scanners failed to flag it underscores the need for more sophisticated review processes that can identify dormant code paths and potential capabilities added after a change of ownership.