Build1 publisher3 min readPublished
KREMLIN forges Chromium's Secure Preferences HMACs with keys already on the endpoint
Elastic Security Labs describes a Brazilian banking operation that edits a Chrome or Edge profile and then signs its own edit using the OSCrypt and App-Bound keys sitting on the same machine. The browser loads the extension as approved.
The Engineer · Build desk
What happened
- Elastic Security Labs documented KREMLIN, a Brazil-focused banking operation that modifies Chromium Secure Preferences so Chrome or Edge loads a malicious extension the user never approved.
- Infection begins when someone opens a JavaScript file disguised as a bank receipt, invoice or payment record, and the loader shows a fake error, checks for an analysis environment, then downloads Node.js.
- Payload locations and extension distribution points are retrieved from an Ethereum smart contract used as a dead-drop resolver.
- The AVSync extension collects cookies, sessions, input, screens and HTTP traffic from the infected profile and receives its commands over WebSocket.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint An extension allowlist enforced by Chromium's own preference signature holds only against editors that lack the profile keys, so any process running as the logged-in user sits outside its scope.
- decision Security teams have to decide whether to actually block writes to the profile directory or settle for alerting on Secure Preferences diffs, because the write-up says integrity monitoring alone is not prevention.
- exposure Removing the extension leaves the stolen cookies and sessions usable, so banking and SaaS accounts remain reachable from the attacker's devices until those sessions are invalidated.
Chromium's integrity check on Secure Preferences answers one question: was this file edited by something that could not compute the right message authentication code. According to Elastic Security Labs, KREMLIN retrieves the OSCrypt and App-Bound keys already present on the endpoint, then regenerates the HMACs and encrypted hashes that correspond to the entries it wrote [7]. A signature you can recompute from material the signer left on disk is a checksum. The extension then appears legitimately registered even though the user never approved it [8].
The write order matters for what a defender sees. The loader waits for a period of user inactivity, closes Chrome or Edge if it has to, and copies the extension into the profile [6]. The profile and its integrity data have to be modified and the browser restarted before the entry takes effect [18]. What a user might notice is a fake error early on and a browser closing and restarting by itself [8]. Elastic's indicator list adds developer mode, Secure Preferences diffs and anomalous extension IDs [13].
The extension is one outcome among several. Elastic's write-up says the chain may lead to remote endpoint control through REMCOS or PULSAR, and that authenticated actions and transfer screens can be modified with HTML injection or clickjacking [10].
Elastic tracked seven campaigns over 15 months, so roughly one new campaign every two months [11][1]. The 1,515 figure rests on something narrower: requests to a single canary domain that a researcher registered, counted at the time of writing [12]. It bounds from below the endpoints that reached that one domain and says nothing about the installed base [2]. For the number to describe your fleet, your users would have to be in the targeted set. The campaigns target banking users in Brazil [1], and delivery depends on someone running a .js file disguised as a receipt, invoice or payment record [3].
Three chokepoints follow from the prerequisites, and the write-up rates them differently. Blocking script execution stops the first stage, and its stated inference is that this prevents the infection vector [14]. Blocking unauthorized writes to profiles or extension loading disrupts the registration stage [15]. Blocking the distribution sites, Ethereum RPC endpoints and C2 hinders later processing, and the same write-up notes that existing infections survive it [16][18].
Hunting guidance points at wscript and cscript as the parents to watch for Node.js execution, scheduled task creation, browser termination and Secure Preferences modification [17]. The dev.to summary does not publish the extension IDs or the distribution domains; it credits Elastic Security Labs as the source and rates the activity High severity [2]. BleepingComputer covered the same activity under the headline "Malware bypasses browser checks to force install Chrome, Edge extensions" [19].
What to watch
- Whether Chromium moves the profile signing keys somewhere a user-level process cannot read.
- Whether another malware family adopts the same Secure Preferences HMAC regeneration step.
- Whether the canary count keeps rising after the campaign rotates distribution through its Ethereum resolver.