Most organizations have a process for evaluating software. Procurement reviews, security assessments, sometimes formal vendor questionnaires. Almost none of them have a process for evaluating what browser extensions their employees are running.
That gap is exactly what this campaign exploits.
Researchers at Socket documented 108 malicious Chrome extensions sharing a single command-and-control backend, collectively installed across roughly 20,000 users. Published under five developer identities, they presented as legitimate tools: Telegram sidebar clients, casual games, YouTube enhancers, translation utilities. The advertised functionality was real enough to pass casual inspection. The behavior running underneath it was not.
“Over the break, we audited browser extensions for a client there were 1,700 different extensions installed. Games, random tools, who knows what else. Mature organizations need an allowlist approach. Honey is a perfect example of something that shouldn’t be allowed in a business environment.”
– Eric Brown, https://www.youtube.com/watch?v=7WuIOTeRff4&list=PLo97iuYkjVbqfiqG3nL_SgOKhm-HDXtFv&index=61
What these extensions actually do:
- 54 extensions abuse Chrome’s OAuth2 integration to capture Google account identity, email, full name, profile picture, account ID, the first time a user clicks a sign-in button
- 45 contain a universal backdoor that opens attacker-chosen URLs automatically at browser launch
- Several exfiltrate Telegram Web session tokens every 15 seconds, and can overwrite localStorage to replace a victim’s live session with one the attacker controls
- Five use Chrome’s declarativeNetRequest API to strip Content Security Policy, X-Frame-Options, and CORS headers before pages load, then inject arbitrary scripts and gambling overlays into the cleared space
All 108 route stolen data to the same IP address.
None of this exploits a Chrome vulnerability. It abuses the extension model working exactly as designed.
Why this beats your existing controls
MFA does not protect you after the token has already been issued. If an employee authenticates to Google Workspace legitimately and an extension captures that OAuth2 token, the attacker has authenticated access, no additional prompt required.
CSP and SameSite cookies do not save you if the extension is the one stripping those headers. You are fighting yourself at that point.
EDR agents see processes, file writes, and network connections. They are not watching an extension modify page content, read session storage, or replace a Telegram session mid-workday. The attack is quiet by design.
A scenario worth considering
A finance lead uses Telegram Web on a managed Chrome profile to coordinate with a distributor. They install a “Telegram sidebar” from the store. It works. Two weeks later, the distributor confirms a change in remittance details, messages from the correct handle, referencing an ongoing shipment. Accounts payable moves six figures to a new IBAN before weekly reconciliation catches the mismatch.
No email compromise. No password phish. Just a browser accessory sitting past MFA.
What to change now
→ Govern extensions like applications. Use Chrome Enterprise policies to allowlist by ID and block everything else. Use ExtensionSettings to restrict host permissions, not just install rights.
→ Kill sync sprawl. Block extension sync across personal and corporate profiles. A personal Chrome profile on a corporate device is BYOD, treat it that way.
→ Constrain where work happens. Require a managed browser for sensitive apps via conditional access. For contractors, provide a managed profile with enforced extension policy.
→ Reduce token value. Prefer phishing-resistant MFA and short session lifetimes. Where supported, use sender-constrained tokens (DPoP) so a stolen bearer token is less useful.
→ Monitor the right signals. Track outbound connections to unfamiliar IPs. Alert on Chrome repeatedly opening the same external URLs at startup. Review OAuth grants for unexpected clients and scopes. Use CRXcavator to score extensions before approval.
→ Rehearse the response. Remove via policy, revoke OAuth sessions in your IdP, force sign-out for affected apps. For Telegram, revoke all Web sessions from mobile. Wipe the Chrome profile to clear residual storage, and purge sync data server-side so it does not quietly reinstall.
The governance question no one is asking
This is not a browser team problem. It is a board-level identity risk that blurs IT, security, and procurement. Someone needs to own a single enforced allowlist, monitor exceptions, and make an explicit decision about whether consumer tools like Telegram belong in corporate browsers at all.
Extensions are inside your Zero Trust perimeter. They run in the same origin context as your most important applications. The browser is already your most privileged workload.
Start managing it like one.
FAQs
Why are malicious Chrome extensions a security risk for businesses?
Malicious Chrome extensions can access browser activity, session data, and web applications employees use for work. That makes them a serious risk to enterprise identity, sensitive data, and business operations.
Can browser extensions get around MFA?
Browser extensions do not need to break MFA if they can capture tokens after a user signs in. Once a valid session is active, an attacker may be able to use that access without another MFA challenge.
What can a malicious browser extension steal?
A malicious extension may capture account details, OAuth data, session tokens, browsing activity, and stored browser information. In some cases, it can also manipulate active sessions inside business applications.
What should happen if a malicious extension is found in the environment?
Respond quickly, but in sequence. Remove the extension through policy, revoke active sessions, review OAuth grants, force sign-outs for affected users, and reset the browser profile if needed. If sync is enabled, clear synced extension data as well so the issue does not return on restore. This is also a strong scenario for a tabletop exercise, particularly for teams that have never tested how they would handle browser-based session theft across IT, security, and business leadership.
