ModHeader Removed: Is 'Dormant' Code Enough to Warrant a Supply Chain Panic?
Just saw the update regarding ModHeader being yanked from the Chrome and Edge stores. With 1.6 million installs, this one hits close to home for a lot of us who rely on header modification for debugging.
The researchers found a hidden collector module that was technically dormant—controlled by an empty allow-list. While there's no evidence of exfiltration yet, the capability was there via the extension's broad permissions (`` and history access). It’s a classic supply chain risk: trusted vendor gets compromised (or goes rogue) and pushes an update.
For those managing enterprise fleets, relying on the store's 'verified' status isn't enough. If you need to audit installs immediately, check against the known ID (idgpnmonknjnojddfkpgkljpfnnfcklj) using this PowerShell snippet to scan registry keys:
Get-ItemProperty "HKCU:\Software\Google\Chrome\Default\Extensions\idgpnmonknjnojddfkpgkljpfnnfcklj" -ErrorAction SilentlyContinue | Select-Object Name, Version
The question is: Do we treat 'dormant' malware with the same severity as active C2 traffic, or is this just a case of 'better safe than sorry' creating unnecessary noise?
I'd argue dormant is just as bad in an audit context. If they can push an update to activate the collector via the remote config (the allow-list), they own the browser whenever they want. We're moving to a whitelist-only model for extensions—anything not explicitly approved gets blocked by Group Policy immediately.
Great catch on the registry path. As a pentester, I love ModHeader for bypassing WAFs during tests, but I never install it on my host browser anymore. I spin up a disposable Chromium instance in a container. It's too easy for these utilities to become attack vectors given the permissions they require to function.
We detected this earlier today via EDR telemetry—not because of malicious traffic, but because the hash changed on the extension file. The version didn't update in the store manifest initially, but the binary on disk was different. If you aren't monitoring browser extension directories for file integrity changes, now is the time to start.
Panic is premature, but complacency is dangerous. This justifies moving to a 'whitelist-only' extension model in your browser GPOs. If you need to validate removal status company-wide before your next audit, use this quick PowerShell check against the known ModHeader ID:
Test-Path "HKCU:\Software\Google\Chrome\Default\Extensions\idgpnmonknjnojddfkpgkljpfnnfcklj"
It’s a fast way to gather evidence of remediation.
This reinforces why software approvals in OT are stricter than IT. To verify if this specific extension is lingering on operator stations without relying on the web store, you can check the local manifest directly. On Windows, extensions reside in C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Extensions. Run this PowerShell snippet to scan for the ModHeader ID and check versions:
Get-ChildItem "C:\Users\*\AppData\Local\Google\Chrome\User Data\Default\Extensions\idgpnmonknjnojddfkpgkljpfnnfcklj" -Recurse -Filter "manifest." | Select-String "version"
If you find versions matching the compromised build, isolate the machine.
The permission scope was certainly the red flag here. For those needing to automate verification without relying on the web store, checking the local Preferences file for the extension ID idgpnmonknjnojddfkpgkljpfnnfcklj is reliable. On Linux or macOS, you can scan profiles with:
grep -r "idgpnmonknjnojddfkpgkljpfnnfcklj" ~/.config/google-chrome/*/Preferences
Has anyone seen the specific C2 domain associated with this collector advertised on any dark markets yet, or is it looking strictly like a reserve capability?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access