Why Google Removed ModHeader: Inside the Spyware Supply‑Chain Attack

Google removed the popular ModHeader Chrome extension after security researchers reverse‑engineered version 7.0.18 and uncovered a hidden spyware SDK that harvests visited domains, encrypts them, and exfiltrates the data to a fake Stanford‑studies endpoint, with a dormant kill‑switch ready for activation via an update.

KooFE Frontend Team
KooFE Frontend Team
KooFE Frontend Team
Why Google Removed ModHeader: Inside the Spyware Supply‑Chain Attack

What happened?

The security research team extracted the official package version v7.0.18 (extension ID idgpnmonknjnojddfkpgkljpfnnfcklj) from the Chrome Web Store and reverse‑engineered it. The signed installer contains a complete, one‑click‑activatable data‑stealing SDK, representing a supply‑chain poisoning attack that leverages the extension’s automatic update mechanism to reach existing users.

Hidden domain‑collection spyware SDK : The SDK listens to chrome.tabs.onUpdated, extracts the host of each visited site, encrypts the host with AES‑GCM, and stores the ciphertext together with a visit count in IndexedDB. During a specific time window—chosen with jittered timestamps to avoid peak traffic—the extension POSTs the batched data to https://api.stanfordstudies.com/app/log.

Masquerade as a date library : Malicious helper functions are hidden in a file named dayjs.min-*.js, pretending to be the popular dayjs date library. The file exports unrelated utilities (browser fingerprinting, domain extraction, sleep handling, midnight‑time helpers), making the malicious code easy to overlook during code reviews.

• Dormant state : The current version’s allowlist variable $w = [] is empty, disabling the collection logic (a kill‑switch). The endpoint, encryption key, schedule, and full pipeline are already in place and can be activated by a future update.

• Fingerprint and anti‑detection : A persistent SHA‑256 fingerprint is generated for each user, and upload timestamps are jittered to avoid bulk‑detection signatures.

Suspicious receiving endpoint : The data is sent to api.stanfordstudies.com, which pretends to be “Stanford Studies – Research” but is unrelated to Stanford University. WHOIS data shows the domain was created in 2022, uses a Lark/Feishu email address, and hides its registrant behind privacy protection. The code also contains the Chinese character “盐” (salt), indicating a Chinese background.

The entire data‑collection, encryption, and exfiltration chain is fully functional. Because the malicious logic is hidden in a library rather than the main extension code, it can remain unnoticed until the kill‑switch is triggered, posing a high‑risk threat.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Chrome Extensioninformation securityMalwareSupply Chain AttackSpywareModHeaderRequestly
KooFE Frontend Team
Written by

KooFE Frontend Team

Follow the latest frontend updates

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.