Modheader Malware Chrome Spyware

More than 800,000 people trusted this extension. Then, one morning, Chrome switched it off and flagged it as malware. Google gave no reason, though. There was no note on what the extension did, and none on what data was at risk.

That extension is ModHeader, a popular developer tool that rewrites HTTP headers on every site you visit. So a malware flag here is a big deal. In response, we pulled the removed build off disk and reversed it. This ModHeader malware analysis walks through the whole case: the hidden pipeline, the forensics, and the indicators of compromise.

First, here is the short version. The details follow below.

What: A ModHeader build ( idgpnmonknjnojddfkpgkljpfnnfcklj , v7.0.18) carried a hidden spyware SDK. Notably, that ID is the official ModHeader listing, and the files carried Chrome Web Store signatures.

Behavior: It harvests the domains you visit. Then it AES-GCM-encrypts the list. Finally, it POSTs the data once a day to api.stanfordstudies.com/app/log .

Hiding place: The malicious helpers sit inside a file named dayjs.min-*.js . In other words, the payload masquerades as a date library.

State: The collector ships dormant behind an empty allowlist ( $w = [] ). Still, the endpoint, key, and scheduler are all present.

Command-and-control: There is none to monitor. The upload is one-way, so the server cannot send commands back.

Adware too: On top of the spyware, it opens an ad tab on every update and shows in-app ads. That behavior fires even on managed enterprise machines.

Reach: ModHeader has 800,000+ users on Chrome, plus a large Edge base. Because the payload rides the official listing, the whole install base is in scope.

Recon: The exfil host hides behind a fake "Stanford Studies - Research" front and a Lark mailbox. In addition, several weak signals point to a Chinese-speaking operator.

Forensics: On the analyzed machine the spyware never fired . However, the extension had locally hoarded the full HTTP headers of all browsing.

Read on for how we found each of these facts.

ModHeader is a popular tool. Developers use it to modify HTTP request and response headers. Therefore it needs broad access to your traffic. That access is normal for its job. Yet it also makes the extension a high-value target.

A trusted extension flagged for malware is the interesting case. Either a clone is wearing the brand, or a trusted extension now carries an injected payload. Both patterns show up often in browser-extension supply-chain attacks. As a result, this ModHeader malware analysis treats the flag as a lead, not a verdict.

The removed extension still sat on disk. The exact path depends on your browser and operating system. On Chrome, check here:

Edge ships the same payload under a different ID. So check there too:

ModHeader is not published on Firefox, so there is no Mozilla add-on to check.

We started with the manifest. The permissions tell you the blast radius fast.

The permission set is broad. It includes , webRequest , declarativeNetRequest , scripting , and a content script on every page. For a header tool, that scope is expected. Still, it means a malicious build already owns your web traffic. Notably, the author field reads modhader@@ . That typo recurs in the code as modhader-tool-root .

, we pulled every URL literal from the bundles. It is the fastest triage step for obfuscated code.

Most results point at modheader.com , the real vendor. However, one host stands out as out of place:

A "Stanford studies" domain has no business inside a header tool. Moreover, /app/log is a generic ingest path. So that became the thread to pull. It lives in one file: assets/src/background-94ad634d.js .

The payload imports its helpers from what looks like the date library.

Yet those exports have nothing to do with dates. Instead, they are operational spyware helpers.

This is deliberate misdirection. A reviewer skims the imports, sees "dayjs", and moves on. Consequently, the ModHeader malware helpers pass review in plain sight.

The diagram below shows the full flow, from browsing to upload. All symbols below are the real minified names. Deobfuscated pseudocode follows each block.

ModHeader malware exfiltration pipeline: domain harvesting, AES-GCM encryption, and daily upload to api.stanfordstudies.com

First, the payload sets up a key, an endpoint, and a fingerprint.

Two points matter here.

The "encryption" is obfuscation, not protection. The AES-GCM key ships in cleartext. Therefore anyone with the extension can decrypt the payload. Its only job is to hide the body from casual network inspection.

The fingerprint is a stable tracking ID. It is SHA-256(Date.now()) . The code generates it once, then stores it. As a result, it acts like a random persistent identifier.

, the collector records domains. It keys them by an encrypted value.

So the store maps each encrypted hostname to a counter. In short, the operator learns which sites you visit and how often. Full URLs and paths are not collected here. Only the host is.

Then the code decides when to send. It uploads at most once per day. Moreover, it waits for a fixed hour that is unique to your fingerprint.

This jitter is clever. Every victim uploads at a different time. Consequently, the traffic is harder to spot on a network monitor. After a successful send, the code clears the local store to remove evidence.

Finally, the whole chain hangs off the tab lifecycle. However, one guard stops it cold.

Here $w is empty. Therefore $w.indexOf(browser) is always -1 . As a result, the guard always returns, and Zw never runs. In this build the collector is present but dormant. Because $w is a hardcoded constant, flipping it on needs a new version. In other words, the real trigger is an auto-update.

Being precise absence matters too. So we checked for the worst behaviors and did not find them.

No remote code execution. There is no eval , no new Function abuse, and no import(" .

No credential theft in the exfil path. The upload carries hostnames, the fingerprint, and the browser type. It does not send cookies or page content.

Cookies are only measured, not sent. A metrics routine reads document.cookie.length for a storage-estimate UI. The cookie value never leaves the page.

Captured headers stay local. The header listeners write to local storage for the extension's own history view.

The spyware was dormant. The adware was not. Users reported new ad tabs opening again and again, even on locked-down company machines. The code explains why.

On every update, the extension force-opens a new active tab to an affiliate network.

Two things stand out.

Every update spawns a tab. Extensions auto-update quietly and often. So the ad tab returns again and again, which matches the reports.

Enterprise machines are not spared. The install tab is skipped when managed profiles exist. However, the update tab has no such check. Therefore company deployments still get the ad tabs.

There is a second ad channel inside the extension itself. The popup fetches ad settings from the vendor, and it can show or close ads.

The UI even spells out the model: "Pausing ads temporarily. To permanently remove ads, consider Upgrade to a paid plan, or Downgrade to a limited plan to opt-out of ads."

So the extension shipped disclosed adware on top of the covert spyware. The two are separate. The adware is visible and annoying, while the spyware is silent. Together, they explain both the user complaints and the malware flag.

The extension's IndexedDB survived removal. It weighed around 178 MB.

So we scanned it for upload markers.

The results were clear:

stanfordstudies returned zero hits across all 178 MB.

lastUploadDate and uploadRecord returned zero hits .

The temp domain store was effectively empty.

Therefore, on this profile, the collector never recorded a domain and never uploaded. That matches the dormant $w = [] gate exactly. In short, your visited-domain list did not leave the machine.

However, one thing did fill 178 MB. The extension's own "history" feature stored the full request and response headers for every page. The dominant keys were requestHeaders , responseHeaders , details , and tabStartTime .

This data never left the disk. Still, it is sensitive at rest. Headers often hold Authorization tokens, session cookies, and internal URLs. So you should wipe this store regardless of whether the spyware fired.

Many readers ask a fair question. Is there a C2 channel to monitor? In short, no.

The upload is strictly one-way. The fetch response body is never read. There is no .json() , no .text() , and no .ok check on the . Furthermore, the operational constants are hardcoded and never reassigned from a server. Therefore api.stanfordstudies.com is a drop box, not a controller. It cannot task the extension.

The real control channel is the extension auto-update. To flip the dormant collector live, an operator must ship a new version. That is exactly the vector the stores neutralize when they delist an extension.

We did not stop at the code. Instead, we profiled the exfil domain with passive and active recon. So here is what the infrastructure itself reveals.

Second, the API host behaves like a drop box, not a website.

The domain was created on 2022-05-09 through Squarespace. Its WHOIS is privacy-redacted.

Its mail runs through larksuite.com (Lark / Feishu). This points to a Chinese-speaking operator. Notably, that matches the 盐 ("salt") string baked into the code.

api.stanfordstudies.com resolves to a single AWS EC2 host ( 3.147.61.167 , region us-east-2).

A probe of the root address timed out. Therefore the host answers only its ingest path, not normal web traffic.

Finally, urlscan.io holds records for the exact endpoint api.stanfordstudies.com/app/log . It also has scans of the host dating back to November 2023.

Taken together, this is a covert ingest endpoint dressed up as academic research. Therefore we rate it malicious.

We then traced the hosting and its history. The result is a commodity, privacy-shielded setup with a longer past than its paperwork suggests.

Host. The endpoint runs on a single AWS EC2 instance, 3.147.61.167 , with reverse DNS ec2-3-147-61-167.us-east-2.compute.amazonaws.com . That places it in AWS us-east-2 (Columbus, Ohio, AS16509 Amazon).

Older than it looks. WHOIS lists a 2022 creation date. However, certificate transparency shows certificates for the domain as far back as 2017. So the name predates the current registration, which points to a re-registration or a change of hands.

Still live. The newest certificate was issued in March 2026. Meanwhile, urlscan.io recorded the /app/log endpoint through 2025 and again in July 2026.

A real operation. Beyond api and www , the domain exposes dev , devlog , and devos subdomains. That is a maintained dev and ops setup, not a throwaway.

Even so, the registrar WHOIS is privacy-redacted, and the servers sit on shared AWS ranges. Therefore the trail stops short of a name.

One detail raises the stakes. The extension ID idgpnmonknjnojddfkpgkljpfnnfcklj is the official ModHeader listing, which serves over 800,000 users. In addition, the build shipped with Chrome Web Store signatures ( _metadata/verified_contents.json ). Because Chrome refuses to run tampered files, the analyzed code is the signed distribution, not a locally modified clone.

However, we cannot prove from the binary alone who added the payload. It could reflect an ownership transfer, an injected monetization SDK, or a vendor decision. That pattern is well documented across the industry. As a result, we present the evidence and mark the authorship question as open.

Role in the ModHeader malware

api.stanfordstudies.com

Encrypted domain-harvest ingest

AWS EC2, root unreachable, "Stanford" disguise, Lark mail

Adware: ad tab opened on every update

AWS S3 + CloudFront, affiliate SaaS, shared across extensions

Privacy-invasive adware

Vendor cloud sync (shown for contrast)

AWS + Google Workspace, transparent

The blast radius is large, because this is the mainline listing. It also spans two browsers.

Chrome: 800,000+ installs, published under "ModHeader".

Edge: the same extension ships under ID opgbiafapkbbnbnjcdomjaghbckfkglc , with a large install base of its own. Microsoft removed it from the Edge Add-ons store on 2026-07-03.

Firefox: no official ModHeader add-on exists, so Firefox users are not affected.

Rating: 2.91 stars from 1,226 votes. That is unusually low for a long-running dev tool.

Listed languages: English and Simplified Chinese ( zh-CN ).

Last listing update: 2026-07-01, which matches the analyzed v7.0.18 build.

The low rating is not random. Recent reviews already flag the extension for adware behavior and affiliated ads. However, those ads are disclosed, and the extension offers an opt-out. Therefore they are a separate, visible complaint. The stanfordstudies.com collector is the opposite. It is covert, encrypted, and offers no notice and no opt-out. So do not confuse the two: the disclosed ads are a trust problem, while the hidden domain harvesting is the actual spyware.

We can sketch the operator only loosely. Importantly, we name no group, and none of these signals is proof.

Mail on Lark. The exfil domain routes email through larksuite.com (Lark / Feishu), a suite common with Chinese-speaking teams.

A Chinese string in the code. The fingerprint salt embeds the character 盐 , which means "salt".

Chinese-language surface. The listing ships a Simplified Chinese locale, and the content script special-cases baidu.com .

A false-flag front. The "Stanford Studies" page borrows a trusted US university name. Clearly, that is misdirection, not a real affiliation.

Taken together, these point weakly toward a Chinese-speaking operator. Still, the infrastructure sits on AWS, and the WHOIS is privacy-redacted. As a result, we cannot tie it to a named actor from open sources alone.

Here is the risk at a glance.

Domain harvesting to stanfordstudies.com

Visited hostnames, fingerprint, browser

New tab on every update, incl. managed machines

Full headers of all browsing

Read/modify all HTTP traffic

In plain terms, nothing was exfiltrated on this machine. Yet the ModHeader malware shipped a complete, keyed, endpoint-ready spyware pipeline. It was one code change from active. Meanwhile, it warehoused sensitive header data locally. That combination is a fair basis for a takedown.

Follow these steps in order.

Confirm the browser disabled the extension. Chrome and Edge usually do this automatically.

Delete the leftover storage directories listed below.

Block and log DNS for api.stanfordstudies.com .

Reinstall a header tool only from a source you trust.

On Edge, the same folders live under Microsoft Edge/ instead of Google/Chrome/ , and the extension ID is opgbiafapkbbnbnjcdomjaghbckfkglc .

Use these hunts and heuristics.

Grep unpacked extension directories for the IOC strings below.

Alert on any extension that POSTs an opaque, encrypted body to a non-vendor domain.

Flag operational helpers exported from a vendored library file as a code smell.

Use these IOCs to hunt for the same ModHeader malware SDK elsewhere.

Files (this build's Vite hashes)

For reference, here is the minified-to-meaning map.

exfil URL api.stanfordstudies.com/app/log

browser allowlist gate (empty = dormant)

fingerprint salt mod盐header

fp = SHA-256(Date.now()) install ID

record a visited domain

upload decision + clear-on-success

per-fingerprint time-of-day gate

browser id / host / midnight / sleep

For wider context on how trusted extensions turn hostile, see the following external reports.

Chrome Extension Turns Malicious After Ownership Transfer (The Hacker News)

Browser extensions pushed malware to 4.3M Chrome and Edge users (The Register)

Extension developers sell the data of at least 6.5M users (LayerX)

A study on malicious browser extensions in 2025 (arXiv)

This analysis is static plus on-disk forensics of a single installed build. We assert no attribution. If you can confirm whether the official Web Store served this exact build, please reach out to HackIndex Research.