KREMLIN Banking Malware (REF9334): Detecting and Removing Malicious Chrome and Edge Extensions Stealing Session Tokens

Elastic Security Labs has disclosed a previously undocumented Brazilian banking malware operation, tracked as REF9334, that delivers a toolkit called KREMLIN. Active since at least May 2025, the campaign impersonates roughly a dozen Brazilian financial institutions and, critically, does not rely on a traditional desktop trojan alone — it installs a malicious browser extension into Google Chrome and Microsoft Edge that steals banking credentials and, more dangerously, session tokens.

That second point is what should get every defender's attention. Session token theft defeats MFA. Once an attacker holds a valid authenticated session cookie for a banking portal, your one-time codes, push approvals, and hardware tokens are irrelevant for that session. This is the same strategic shift we have watched info-stealers make over the past two years, now packaged into a persistent browser extension with direct visibility into everything the victim does in the browser.

While the current targeting is Brazilian banks, the technique is fully portable. The lure infrastructure, the extension-loading mechanism, and the token-harvesting logic transfer trivially to any geography. If your organization has users in Brazil, business with Brazilian financial institutions, or simply wants to get ahead of the inevitable technique copycats, this is the moment to build detections — not after your incident response retainer gets exercised.

Technical Analysis

Threat overview

• Threat actor / campaign: REF9334 (Elastic Security Labs tracking designation)
• Malware toolkit: KREMLIN
• Active since: At least May 2025, still active as of this reporting
• Targeting: Customers of approximately a dozen Brazilian banks, via impersonation lures (phishing pages and messages mimicking legitimate bank communications)
• Delivery mechanism: Social engineering lures directing victims to install what is presented as a bank "security module" or required component — a long-standing social engineering pattern in the Brazilian banking malware ecosystem
• Payload: A malicious browser extension installed into Chrome and Edge, granting the attacker in-browser visibility and manipulation capability
• Objective: Harvesting of banking credentials and session tokens for account takeover and fraudulent transactions

No CVE is associated with this campaign — this is not a vulnerability exploitation story. It is a social engineering and browser-abuse story, which means your patch management program will not save you here. Detection engineering and extension governance will.

Why a malicious extension is the right tool for this job

Traditional Brazilian banking trojans (Grandoreiro, Mekotio, and their kin) historically relied on overlay windows, screen monitoring, and keylogging. Those techniques are noisy, AV-visible, and increasingly fragile against modern browser process isolation. A malicious extension solves the attacker's problems elegantly:

1. Native access to the DOM. An extension with broad host permissions (<all_urls> or explicit bank domains) can read, inject, and modify page content — including credential fields — without touching the browser's process memory in ways EDR watches.
2. Session token access. Extensions can read cookies for permitted domains via the cookies API, or simply observe authenticated traffic. This enables session replay from attacker infrastructure.
3. Persistence by design. Extensions survive browser restarts and reboots. Once installed, the implant is durable without any of the registry Run keys or scheduled tasks defenders hunt for.
4. Living inside a trusted process. All malicious activity executes inside chrome.exe or msedge.exe. There is no suspicious child process chain unless the installer itself is sloppy.

How the extension gets installed — and what defenders can observe

Threat actors installing extensions outside the official Chrome Web Store / Edge Add-ons store generally rely on a small set of techniques, each with distinct forensic artifacts:

• Developer-mode / unpacked extension loading: The malware drops the extension to disk (commonly under %LOCALAPPDATA%, %APPDATA%, or a subfolder of ProgramData) and forces Chrome/Edge to load it unpacked, sometimes combined with command-line flags like --load-extension. Observable via browser command lines and unexpected directories containing a manifest.json.
• Registry-based force-install: On managed-capable machines, attackers abuse the enterprise policy keys HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist or the Edge equivalent (HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist) to silently install an extension from an update URL they control. Any write to these keys outside your software deployment system is a high-fidelity signal.
• Preferences tampering: Direct modification of the browser's Secure Preferences / Preferences files in the user profile to register the extension. Chrome's integrity checks have made this harder, but determined actors still attempt it.

The REF9334 lure flow — a fake bank page instructing the user to install a "security plugin" — means the initial execution often involves a downloader MSI or executable run by the user, followed by extension staging. That installer stage is your best detection surface at the endpoint; the extension behavior is your best surface at the browser and identity layers.

Exploitation status

This is confirmed active in-the-wild exploitation with a named, tracked campaign operating for over a year. It is not theoretical. There is no CISA KEV entry (no CVE exists), and no vendor patch is coming — the defense is entirely in detection engineering, browser hardening, and user controls.

Detection & Response

The detections below target the highest-fidelity, lowest-noise observables for this intrusion class: extension installation telemetry, browser policy abuse, and unpacked extension artifacts on disk. These generalize beyond KREMLIN to the entire malicious-extension threat class, which is exactly what you want from a durable detection investment.

Sigma Rules

---
title: Browser Extension Force-Install Policy Registry Modification
id: 8c2f4a91-3d7b-4e5f-9a21-6b8c0d1e2f3a
status: experimental
description: Detects writes to Chrome or Edge ExtensionInstallForcelist policy registry keys, a technique used to silently install malicious browser extensions such as those deployed by REF9334/KREMLIN. Legitimate writes should only originate from enterprise management tooling.
references:
  - https://thehackernews.com/2026/09/kremlin-banking-malware-hijacks-chrome.html
  - https://attack.mitre.org/techniques/T1176/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1176
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|contains:
      - '\Policies\Google\Chrome\ExtensionInstallForcelist'
      - '\Policies\Microsoft\Edge\ExtensionInstallForcelist'
      - '\Policies\Google\Chrome\ExtensionInstallSources'
      - '\Policies\Microsoft\Edge\ExtensionInstallSources'
  filter_mgmt_tools:
    Image|endswith:
      - '\ConfigMgr\'
      - '\ccmexec.exe'
      - '\IntuneManagementExtension\'
      - '\msiexec.exe'
  condition: selection and not filter_mgmt_tools
falsepositives:
  - Enterprise software deployment systems pushing sanctioned extensions (tune the filter to your actual management tooling)
  - GPO processing (typically visible as Group Policy client-side activity, not direct registry writes from odd binaries)
level: high
---
title: Browser Launched With Load-Extension Command Line Flag
id: 3f7a9c52-1e4d-4b68-8d30-2a5b6c7d8e9f
status: experimental
description: Detects Chrome or Edge launched with the --load-extension flag, which loads an unpacked extension from disk. This is a known technique for installing malicious extensions outside the official stores, as used by KREMLIN/REF9334 and similar banking malware.
references:
  - https://thehackernews.com/2026/09/kremlin-banking-malware-hijacks-chrome.html
  - https://attack.mitre.org/techniques/T1176/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1176
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
    CommandLine|contains:
      - '--load-extension'
  filter_automation:
    CommandLine|contains:
      - '--headless'
      - 'selenium'
      - 'webdriver'
  condition: selection and not filter_automation
falsepositives:
  - Browser extension developers loading their own code
  - QA/automation frameworks (filtered above; expand as needed)
level: high
---
title: Manifest File Dropped In Suspicious User Directory
id: 5b1d8e43-7f2a-4c96-a104-9d3e4f5a6b7c
status: experimental
description: Detects creation of manifest.json files (browser extension manifests) in user-writable directories outside legitimate extension and development locations. Malicious unpacked extensions are commonly staged in AppData or ProgramData subfolders.
references:
  - https://thehackernews.com/2026/09/kremlin-banking-malware-hijacks-chrome.html
  - https://attack.mitre.org/techniques/T1176/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1176
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\AppData\Local\'
      - '\AppData\Roaming\'
      - '\ProgramData\'
      - '\Temp\'
      - '\Downloads\'
  selection_name:
    TargetFilename|endswith: '\manifest.json'
  filter_legit:
    TargetFilename|contains:
      - '\Google\Chrome\User Data\'
      - '\Microsoft\Edge\User Data\'
      - '\node_modules\'
      - '\AppData\Local\Programs\'
      - '\AppData\Roaming\npm\'
  condition: selection_path and selection_name and not filter_legit
falsepositives:
  - Web development activity (PWA manifests, build outputs)
  - Electron app installs — tune filters per environment
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts for the two strongest endpoint signals of this campaign class: force-install registry policy writes and browsers launched with extension-loading flags. Run it across your environment and treat any unmanaged hit as a triage candidate.

let Lookback = 14d;
let RegHits = DeviceRegistryEvents
| where Timestamp > ago(Lookback)
| where RegistryKey has_any ("ExtensionInstallForcelist", "ExtensionInstallSources", "ExtensionInstallAllowlist")
| where InitiatingProcessFileName !in~ ("ccmexec.exe", "msiexec.exe", "Microsoft.IntuneManagementExtension.exe")
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, RegistryValueData,
          InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName;
let CmdHits = DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where FileName in~ ("chrome.exe", "msedge.exe")
| where ProcessCommandLine has_any ("--load-extension", "--disable-extensions-except")
| where ProcessCommandLine !has_any ("selenium", "webdriver", "--headless")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine, AccountName;
union RegHits, CmdHits
| sort by Timestamp desc

A complementary identity-layer hunt: because KREMLIN exfiltrates session tokens, look for impossible-travel or anomalous-session patterns on banking and financial SaaS logins. If you route proxy logs into Sentinel, also hunt for navigation to lookalike domains of the impersonated Brazilian banks (freshly registered domains with bank names in the FQDN).

Velociraptor VQL

This artifact enumerates installed browser extensions across all user profiles on an endpoint by parsing each profile's Preferences file, and pairs that with a sweep for unpacked-extension manifests staged in suspicious user-writable paths. Deploy it as a hunt across Windows endpoints during triage.

-- Hunt for suspicious browser extension artifacts across Chrome and Edge profiles
LET manifest_hits = SELECT FullPath, Mtime, Size,
       read_file(filename=FullPath, length=2048) AS ManifestHead
FROM glob(globs=[
  "C:/Users/*/AppData/Local/**/manifest.json",
  "C:/Users/*/AppData/Roaming/**/manifest.json",
  "C:/ProgramData/**/manifest.json"
], accessor="ntfs")
WHERE FullPath !~ "Google\\\\Chrome\\\\User Data"
  AND FullPath !~ "Microsoft\\\\Edge\\\\User Data"
  AND FullPath !~ "node_modules"
  AND ManifestHead =~ "manifest_version"

SELECT FullPath AS SuspiciousManifest,
       Mtime AS StagedTime,
       Size AS ManifestSize,
       ManifestHead
FROM manifest_hits

For live response on a confirmed host, extend this with a second query against the user's browser Preferences JSON (C:/Users/*/AppData/Local/{Google/Chrome,Microsoft/Edge}/User Data/*/Preferences) extracting the extensions.settings keys so analysts can review every installed extension ID, its install source, and its granted permissions.

Remediation / Verification Script

Use this PowerShell on suspected hosts (or at scale via your RMM/EDR) to enumerate force-installed extension policies and unpacked extension artifacts, and optionally neutralize unauthorized force-install entries. Review output before deleting anything in a production environment.

# KREMLIN / malicious-extension triage and cleanup — run elevated
$report = @()

# 1. Check extension force-install and policy abuse keys for Chrome and Edge
$policyPaths = @(
  'HKLM:\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist',
  'HKLM:\SOFTWARE\WOW6432Node\Policies\Google\Chrome\ExtensionInstallForcelist',
  'HKLM:\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist',
  'HKLM:\SOFTWARE\WOW6432Node\Policies\Microsoft\Edge\ExtensionInstallForcelist'
)
foreach ($p in $policyPaths) {
  if (Test-Path $p) {
    $props = Get-ItemProperty -Path $p
    $props.PSObject.Properties | Where-Object { $_.Name -notmatch '^PS' } | ForEach-Object {
      $report += [pscustomobject]@{
        Type = 'ForceInstallPolicy'; Path = $p; Name = $_.Name; Value = $_.Value
      }
    }
  }
}

# 2. Sweep user profiles for unpacked extension manifests in suspicious locations
$suspectRoots = @("$env:LOCALAPPDATA", "$env:APPDATA", 'C:\ProgramData')
foreach ($root in $suspectRoots) {
  Get-ChildItem -Path $root -Recurse -Filter 'manifest.json' -ErrorAction SilentlyContinue |
    Where-Object {
      $_.FullName -notmatch 'Google\\Chrome\\User Data|Microsoft\\Edge\\User Data|node_modules'
    } | ForEach-Object {
      $content = Get-Content $_.FullName -Raw -ErrorAction SilentlyContinue
      if ($content -match '"manifest_version"') {
        $report += [pscustomobject]@{
          Type = 'UnpackedExtensionManifest'; Path = $_.FullName
          Name = $_.Directory.Name; Value = ($content.Substring(0, [Math]::Min(300, $content.Length)))
        }
      }
    }
}

$report | Format-List
$report | Export-Csv -Path "$env:TEMP\extension_triage.csv" -NoTypeInformation

# 3. OPTIONAL: Remove unauthorized force-install entries (uncomment after review)
# foreach ($entry in ($report | Where-Object Type -eq 'ForceInstallPolicy')) {
#   Remove-ItemProperty -Path $entry.Path -Name $entry.Name -Force
#   Write-Host "Removed force-install entry: $($entry.Path) -> $($entry.Name)"
# }

# 4. Check for browsers running with extension-loading flags right now
Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match '^(chrome|msedge)\.exe$' -and
                 $_.CommandLine -match '--load-extension|--disable-extensions-except' } |
  Select-Object ProcessId, Name, CommandLine | Format-List

Cross-reference any discovered extension IDs against the Chrome Web Store and your approved-extension inventory. Unknown IDs with permissions like cookies, webRequest, tabs, or <all_urls> on a banking customer's machine are your smoking gun.

Remediation

Because there is no CVE and no patch, remediation is a layered hardening and eradication exercise:

Immediate containment (confirmed or suspected hosts):

1. Isolate the endpoint from the network. Session tokens are the prize — assume active session replay is in progress.
2. Remove the malicious extension from Chrome and Edge on the affected host, and delete any staged unpacked-extension directories identified by the script above.
3. Remove any unauthorized ExtensionInstallForcelist registry entries.
4. Revoke sessions everywhere. Force sign-out and token revocation for the user's banking sessions, and — because users reuse browsers — for corporate SSO, email, and financial SaaS. This step is non-negotiable; deleting the extension does nothing for tokens already exfiltrated.
5. Reset credentials for any account accessed in the browser since the suspected installation date.
6. Contact the affected financial institution's fraud team to flag the account for unauthorized transaction review.

Organization-wide hardening:

1. Deploy an extension allowlist. Use Chrome's ExtensionInstallBlocklist set to * combined with ExtensionInstallAllowlist for approved IDs (and the Edge equivalents). This is the single most effective control against this entire threat class — it converts a silent install into a blocked event.
2. Restrict developer mode. Set the DeveloperToolsAvailability and related extension developer-mode policies to prevent loading unpacked extensions where the business does not require it.
3. Alert on policy key writes. Ship the Sigma rule above into production; any write to force-install keys outside your deployment pipeline should page the SOC.
4. Block the lure stage. Add lookalike-domain detection for your brand and (for organizations with Brazilian exposure) for the impersonated banks. Enforce DMARC and deploy banner warnings on external mail impersonating financial institutions.
5. User education targeted at this exact lure. "Your bank will never ask you to install a security plugin from a link" is a concrete, teachable message. Brazilian banking malware has relied on the fake-security-module lure for over a decade because it keeps working.
6. Token-theft-resistant authentication. Where your own applications are concerned, adopt phishing-resistant MFA (FIDO2/passkeys) and token-binding controls such as short session lifetimes and device-bound session credentials, which sharply reduce the value of a stolen cookie.

Threat hunting follow-up: Run the KQL and VQL content above retroactively over at least 90 days. REF9334 has been active since May 2025 — a 14-day window will miss long-dwell infections. Any hit should trigger the full containment sequence, not just extension removal.

Conclusion

KREMLIN/REF9334 is a clear signal of where commodity financial malware is heading: away from noisy desktop trojans and into the browser, where MFA can be sidestepped via session token theft and where activity hides inside a process most EDR policies treat as benign. The good news for defenders is that this technique has a narrow, highly observable installation surface. Extension force-install policies, --load-extension flags, and unpacked manifests in user-writable paths are all loud signals — if you are looking. Deploy the allowlist, wire up the detections, and rehearse the session-revocation playbook before you need it.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub