Security · 17 Sep 2026 · Rob Nidschelm

This Malware Makes Chrome Trust an Extension You Never Approved

The familiar browser prompt is supposed to be a moment of choice: do you want this extension to access your browsing? In a banking-malware operation examined by Elastic Security Labs, the malicious extension arrives without that choice. Malware changes the browser’s own configuration so it loads the extension as though the user approved it.

Elastic’s 14 September report describes KREMLIN, a toolkit used in a Brazilian-focused operation tracked as REF9334. A user executes a JavaScript lure disguised as a financial or business document; the chain installs malware and a malicious Chrome or Edge extension. This is not a report of an untouched browser being infected merely by visiting a website, or a newly disclosed browser zero-day.

The trusted configuration is part of the attack

The installer modifies Chromium’s Secure Preferences and regenerates integrity values, enabling the extension without ordinary user approval. The extension can collect credentials and session data and interfere with pages. Elastic tracked seven campaigns across 15 months and observed 1,515 infected systems contacting a canary domain; 98.75% were in Brazil. Those figures describe the researchers’ observations, not a worldwide victim total.

Earlier Synacktiv research explains why a valid browser configuration is not necessarily a record of informed consent. Extension-loading settings are stored in local preference files and protected by integrity checks. A sufficiently capable local process can target those checks. Once loaded, an extension operates inside the browser environment, where data handled by the browser may be available to it even when protected at rest.

The distinction matters for defenders. “The browser accepted it” is an observation about a loading mechanism. It is not independent evidence that a person wanted it, that the endpoint is clean, or that every action within a signed-in session was legitimate. Those are different claims and need different evidence.

The banking document is not the end of the incident

Elastic also describes configuration retrieved through Ethereum smart contracts and a temporary disruption achieved by registering a domain used in an anti-analysis check. Neither detail means Ethereum users were broadly compromised or that every infected host was cleaned. The name KREMLIN is not evidence of Russian attribution: Elastic’s findings point to a Brazilian-focused operation.

For a business, the useful response is broader than removing an unfamiliar add-on. If an endpoint can manipulate a browser profile, it is important to assess what the signed-in browser could reach during the affected period. A finance user’s bank session is one concern; mail, cloud consoles and administrative services may deserve separate review according to actual access and evidence. That is BlackTree’s risk assessment, not a claim that this campaign compromised those services.

What teams should check next

• Investigate the endpoint, not just the extension. Preserve relevant evidence and trace the original execution and subsequent changes. Removing one visible component does not establish that the rest of the chain has gone.
• Compare the actual extension inventory with policy. Look for unapproved local or developer-mode installations and unexplained profile changes. Account for legitimate development and enterprise deployment before declaring an item malicious.
• Review script execution controls. Check whether users need to execute downloaded JavaScript files and whether application-control rules cover that route. Test proposed restrictions against genuine business workflows.
• Scope potentially exposed sessions. Where theft is supported by evidence, coordinate session revocation and credential recovery with the service owner. Use a known-clean device for recovery rather than relying on the affected browser.
• Hunt using the published research. Elastic supplies indicators and behavioural detail. Treat matches as investigative leads and preserve their context; do not infer an infection solely from a connection to a legitimate hosting or blockchain service.
• Validate the return to service. Check the rebuilt or remediated endpoint, approved extensions and monitoring. Record why the team believes the device and relevant sessions are trustworthy again.

A current browser remains important, but “fully updated” and “running on a trustworthy endpoint” are not interchangeable. BlackTree’s previous reporting on the consequences of a stolen session illustrates why the response must follow the access available to an intruder, rather than stopping at the password field. It is related context, not evidence of a connection between the incidents.

The uncomfortable question is not whether you remember approving an extension. It is whether your security process can tell the difference between a browser configuration you chose and one malware made on your behalf.

Sources

• Elastic Security Labs, KREMLIN malicious browser extension investigation, published 14 September 2026.
• Synacktiv, The Phantom Extension: Backdooring Chrome Through Uncharted Pathways, technical background on local extension installation and integrity checks.