KREMLIN / REF9334 — Banking Browser-Extension Hunt

KREMLIN is a Brazilian banking-malware toolkit — named by its own author "Kr3mlin4rt1st," with no actual Russian nexus — that Elastic Security Labs has tracked as REF9334 across seven campaigns since May 2025 (reported 2026-09-15). Victims manually run a JavaScript file disguised as a bank receipt or invoice; a multi-stage loader checks for sandboxes, establishes scheduled-task persistence, resolves command-and-control locations from an Ethereum smart contract or Cloudflare Workers, and drops a C++ installer that sideloads through a legitimate SentinelOne binary.

The operation's signature capability is forcing a malicious Chrome/Edge extension into the browser without the Web Store and without user consent: the installer force-closes the browser, extracts Chromium's OSCrypt and App-Bound encryption keys (via DPAPI and a debugged browser process), then rewrites the profile's Secure Preferences file — regenerating the HMACs and encrypted hashes Chromium itself uses to prove the file hasn't been tampered with. The browser loads the extension as though the user had approved it. The extension then harvests cookies, session storage, browsing history, screenshots, and keystrokes from roughly a dozen Brazilian banks, exfiltrating an RC4-encrypted archive to attacker infrastructure. Elastic disrupted over 1,500 infections (98.75% in Brazil) by sinkholing the malware's own sandbox-canary domain.

Falcon telemetry cannot see inside the extension's in-browser JavaScript (keylogging, screenshot capture, cookie theft happen entirely in-page), so detection here is necessarily about the surrounding host behavior: the scheduled task, the DLL sideload, the debugger-attached browser process, and the Secure Preferences write itself. That gap is exactly why the hardening section (§12–13) — extension allowlisting, blocking the three known malicious extension IDs, and disabling unmanaged Developer Mode — carries as much weight in this pack as the hunt queries do.

Defender priority: hunt for (1) Chrome/Edge Secure Preferences modified by a non-browser process and (2) chrome.exe/msedge.exe launched with --remote-debugging-port. Both behavioral signals catch the technique regardless of which of the 20+ rotating C2 domains this campaign uses next — infrastructure IOCs alone will not survive the next rebrand (donalurdes → maria → haria → cremeb → zaviro/volmira already happened once).

Decisions made against the operator brief: two indicators supplied in the tasking brief could not be traced to any fetched source text after a targeted re-search — IP 45.90.13[.]77 (only 45.90.13.210 appears in the Elastic report; same /24, different host, not corroborated) and Cloudflare Workers hostname find-postman.ddesdokww.workers.dev (no fetched source mentions this string at all). Per the no-invented-IOC rule, both are omitted from this pack rather than shipped on the brief's word alone. The Workers hostname version.checkeligibitily.workers.dev is likewise not shipped as an atomic block/detect entry — the source only describes the resolver as serving "version, graph subdomains" without giving the full hostname string verbatim — but graph.checkeligibitily.workers.dev IS shipped, because that exact string appears in the source's quoted resolver URL.

Trust-the-source resolution: the operator brief's lure-filename pattern (ComprovanteBank_DD-MM-YYYY.js) differs slightly from what Elastic actually documented (COMPROVANTE_{Bank}_DD-MM-YYYY.{10 digits}.js and ComprovanteOriginal_{Bank}_DD-MM-YYYY.{10 digits}.js). This pack uses the source's actual pattern throughout.

Prompt-injection check: none of the three fetched sources contained any text directed at the research agent (no embedded instructions, no "ignore previous instructions," no claimed authorization to skip steps or fetch additional URLs). All three are cited normally.

Hunt Hypotheses

1. (High) Persistence via a scheduled task named MicrosoftNodeRuntimeUpdater or AcrobatBrowserExtension is present on hosts compromised by this loader family.
2. (High) Chrome/Edge Secure Preferences files are being modified by a process other than the browser itself — the mechanical fingerprint of forced extension registration.
3. (High) chrome.exe/msedge.exe processes are being launched with remote-debugging flags to extract OSCrypt/App-Bound keys via ReadProcessMemory.
4. (High) A binary named SentinelMemoryScanner.exe is running from a path outside a genuine SentinelOne installation (DLL sideload staging).
5. (Medium) node.exe is being spawned under conhost.exe --headless, matching the first-stage persistence execution pattern.
6. (Medium) wscript.exe/cscript.exe are executing JavaScript files whose names match the COMPROVANTE banking-receipt lure pattern.
7. (High) Endpoints are resolving DNS for known KREMLIN/REF9334 C2 infrastructure (current or historical).
8. (High) One of the three known malicious extension IDs is present in a Chrome/Edge profile.

Attack Chain

Non-CQL checks that complement the Falcon queries in §8, especially where a Critical File Monitoring rule is not yet deployed.

• Windows Security Event 4698 (scheduled task created) — filter TaskName for MicrosoftNodeRuntimeUpdater or AcrobatBrowserExtension; cross-reference the creating process against known-admin tooling.
• Sysmon Event ID 7 (image/DLL load) — flag SentinelAgentCore.dll loaded by a process whose path is not under the standard SentinelOne install directory.
• Sysmon Event ID 11 (FileCreate) — flag writes to ...\User Data\Default\Secure Preferences, ...\User Data\Local State, or any ...\User Data\Default\Extensions\{extension-id} path where the writing image is not chrome.exe or msedge.exe.
• Chrome/Edge policy audit (chrome://policy / edge://policy) — confirm ExtensionInstallBlocklist and ExtensionSettings are actually applied on the endpoint, not merely configured centrally.
• chrome://extensions with Developer Mode manually enabled — visually confirm no unpublished/unexpected extension is present; the three known IDs will not show a Web Store listing if inspected.
• DNS/proxy log review for the sinkholed canary domain creamp1eonlyfans.net — any resolution attempt is a confirmed-infection signal (see the "do NOT block" note in §4/§10).
• Manual IR / live-response — enumerate open mutexes for ClarinhoQueSim-XEDA2O on a suspect host (no native Windows Event Log source for mutex creation; requires a live-response tool or memory capture).

Promote the five highest-confidence, lowest-FP queries to Custom IOA rule groups after the 14-day silent-run validation in §11. Keep Q2, Q3, Q4, and Q5 as Investigate-only hunts until their FP-medium tuning exclusions are confirmed in your tenant.

Triage & Response (for any hit above)

1. Network-contain the host in Falcon before further investigation — this is an active credential-theft chain with a live exfil channel.
2. Pull the process tree for the alerting event; confirm parent chain against §3's attack chain (JS lure → wscript/cscript → scheduled task → conhost/node → installer).
3. Check for the Q4/Q9 Secure Preferences / extension-ID fingerprint even if the alert came from a different query — if present, assume the extension is already force-installed.
4. Pull local Chrome/Edge chrome://extensions (Developer Mode on) via live response; document any extension ID not matching your organization's approved/forced list.
5. Run Q8 environment-wide, scoped to the last 30 days, to find other hosts beaconing to the same infrastructure.
6. Rotate credentials and revoke active sessions for any account whose browser profile shows the Q4/Q9 fingerprint, prioritizing banking and password-manager-linked accounts.
7. Escalate to IR if OSCrypt/App-Bound key theft is confirmed (Q5 hit + Q4 hit on the same host within the same session) — this indicates DPAPI-protected secrets beyond the browser may be exposed.

Pivot Queries

// PIVOT: host-scoped — all process activity in the hour around a Q1/Q4/Q6 hit
#event_simpleName=/^ProcessRollup2$/
| aid=REPLACE_WITH_AID
| table([ComputerName, UserName, FileName, ParentBaseFileName, CommandLine, aid])

// PIVOT: environment-wide — any other host resolving the same C2 domain as a confirmed hit
#event_simpleName=/^DnsRequest$/
| DomainName=REPLACE_WITH_CONFIRMED_DOMAIN
| table([ComputerName, UserName, DomainName, aid])

Because the extension's in-browser data theft (§5, §15) is invisible to EDR, hardening carries more of the defensive weight than usual for this threat. The controls below target the three chokepoints the attack chain cannot avoid: getting the lure to execute, forcing the extension in, and reaching C2.

Playbook 1 — Disable Windows Script Host (blocks the .js lure's execution vector)

MITRE: T1204.002 → M1038, M1042   Prerequisites: confirm no legitimate logon/legacy scripts on the target ring depend on wscript.exe/cscript.exe (rare but check any old VBS/JS logon scripts first)   Reboot required: No

\# Disable Windows Script Host for both wscript.exe and cscript.exe
$path = 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings'
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name 'Enabled' -Value 0 -PropertyType DWORD -Force | Out-Null
Write-Output "Windows Script Host disabled (Enabled=0)"

GPO path: deploy the above via a registry preference item, or use Administrative Templates if your baseline ADMX includes a WSH template. Verify: (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings' Enabled).Enabled should return 0; attempting to run a .js file via double-click should show "Windows Script Host access is disabled."

Rollback: Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings' Enabled 1 (or delete the value) — takes effect immediately, no reboot needed.

Playbook 2 — Block Known KREMLIN Extension IDs + Move to Allowlist-Only

MITRE: T1176 → M1038   Prerequisites: Chrome/Edge ADMX templates installed in your GPO/Intune environment; inventory of currently force-installed and user-installed extensions before changing the default installation mode   Reboot required: No (browser restart to pick up policy)

// Chrome/Edge ExtensionSettings policy (JSON) -- deploy via GPO "Extension management settings" or Intune OMA-URI
{
  "ndpbidppejfanjbhfgjlohfanbfbklff": { "installation_mode": "blocked" },
  "djodclnjknbpambeaaapadmdfhmbpeog": { "installation_mode": "blocked" },
  "cdgcjghdeinagopbaobhmaefigoafaaa": { "installation_mode": "blocked" },
  "*": { "installation_mode": "blocked" }
}

Verify: on a test endpoint, chrome://policy should show ExtensionSettings applied with the three blocked IDs; attempt to sideload one of the three IDs in a lab VM and confirm Chrome refuses to load it.

Rollback: revert the GPO/Intune ExtensionSettings value to your prior JSON (back it up before this change) and force a policy refresh (gpupdate /force or Intune sync).

Playbook 3 — Enable ASR Rule: Block JavaScript/VBScript from Launching Downloaded Executable Content

MITRE: T1204.002, T1059.007 → M1040   Prerequisites: Microsoft Defender Antivirus active or passive mode; roll out to a pilot ring in Audit before Block   Reboot required: No

\# Audit mode first (recommended 2-week pilot)
Set-MpPreference -AttackSurfaceReductionRules_Ids d3e037e1-3eb8-44c8-a917-57927947596d -AttackSurfaceReductionRules_Actions AuditMode

\# After a clean audit period, switch to Block
Set-MpPreference -AttackSurfaceReductionRules_Ids d3e037e1-3eb8-44c8-a917-57927947596d -AttackSurfaceReductionRules_Actions Enabled

Verify: Get-MpPreference | Select -ExpandProperty AttackSurfaceReductionRules_Ids should list the GUID with a matching action in AttackSurfaceReductionRules_Actions; review Defender ASR audit events (Event ID 1122/1121) for hit volume before flipping to Block.

Rollback: Set-MpPreference -AttackSurfaceReductionRules_Ids d3e037e1-3eb8-44c8-a917-57927947596d -AttackSurfaceReductionRules_Actions Disabled

Validation gates from §11 apply to every "Good"/"Partial" row above — none of these queries should be promoted to Prevent without the benign-baseline and positive-test steps completed first. The two "Gap" rows tied to in-browser behavior are not closeable by EDR at all; they are the reason §12's extension-allowlisting controls are marked Immediate/Near-Term rather than optional.

Source snapshots saved verbatim at build time: 01-elastic-security-labs.txt, 02-thehackernews.txt, 03-gbhackers.txt in this pack's -sources/ directory.