Built this in my free time and figured this crowd might get some use out of it, or at least tell me what I've got wrong.

Hayabusa, by Yamato Security, is excellent on a single host. You point it at a directory of event logs and get fast Sigma-based detections with an HTML summary. The snag for me is what an engagement actually looks like: a folder of KAPE collections, one per host, some loose and some as VHD/VHDX. I end up mounting each image, running Hayabusa on each host one at a time, then stitching the results together by hand.

Hayabusa-Bulk-Runner does that part. Point it at a folder with one entry per host and it mounts each image and runs Hayabusa on every host, then rolls the lot into a single cross-host triage dashboard showing which hosts are worst and which rules fired where, alongside the per-host reports and timelines. It is not a detection engine and not a replacement. Every detection is still Hayabusa's. It just does the batching and the triage view on top.

Evidence handling, since it matters here: it only ever reads the evidence. Disk images are never mounted directly. It creates a read-only differencing child over the image and mounts that, and it hashes the source before and after to show it was untouched.

Upfront: I built it with Claude Code, partly to see how far I could get on something I'd actually use. So treat it like any tool you didn't write yourself. The code is there to read, it has a Pester suite and CI across PowerShell 5.1 and 7, and I've run it against KAPE output, but verify results before you lean on it for casework. It's early and will have rough edges. MIT licensed. Hayabusa is AGPL and called as a separate program, I don't bundle it or its rules, you bring your own.

Repo: https://github.com/rorywag/Hayabusa-Bulk-Runner
Hayabusa: https://github.com/Yamato-Security/hayabusa

Happy to take bug reports, feature ideas, or a straight "this is wrong because". That's mostly why I'm posting.

We came across a malware sample pushed through a paid search/ad impersonating Claude Code. I reversed it over the past day. Putting the detection content first so if you're not interested in the analysis.

Quick summary: a renamed, legitimately signed JetBrains binary sideloads a malicious libcef.dll, the real payload is a .NET exe hidden inside icudtl.dat, it pulls its C2 from a smart contract on BNB Smart Chain (EtherHiding), and it escalates to SYSTEM by abusing the Steam Client Service.

The payload is hosted on Google Cloud Storage, but the delivery URL carries a Microsoft Advertising click ID, so the ad was most likely served through Microsoft/Bing Ads.

Domains/infra to block or hunt for:

hxxps://storage[.]googleapis[.]com/claudeapi/claude[.]html?msclkid=a5ca8dd81bbc1cea0dcee714b86f8877

BSC contract 0xc1907d7be91f95903ad66d775c397302e7dd9228

eth_call selector 0x6d4ce63c to:
  bsc-dataseed[.]binance[.]org
  bsc-dataseed1[.]defibit[.]io
  bsc-dataseed1[.]ninicoin[.]io

Those RPC nodes are legitimate public infrastructure. Consider alerting on eth_call from noncrypto processes rather than hardblocking if you need it.

Files/paths to look for:

Claude.exe + libcef.dll + icudtl.dat together, outside a JetBrains install

%LOCALAPPDATA%\Cache-<8hex>\  (u.exe / u.dll / u.bin, x\ subfolder)

%TEMP%\w<8hex>\  (launcher.exe + libcef.dll + icudtl.dat + signed.vdf + run.vdf)

%APPDATA%\Roaming\LocalCache\

Mutexes:

Global\WinCacheSync

Global\WinCacheSyncE

Process/behavior to look for:

Claude.exe (jcef_helper.exe) or launcher.exe spawned by steamservice.exe

powershell.exe ... Add-MpPreference -ExclusionPath ...

writes under HKLM\Software\Valve\Steam\Apps\431960\

drop of signed.vdf / run.vdf

outbound eth_call JSON-RPC from a non-crypto process

scheduled task CacheMaintenanceTask

Hashes we observed. Note the Claude.exe hash is a legitimate signed JetBrains file, so label it or you'll alert on real IntelliJ users

Claude.exe (legit JetBrains jcef_helper.exe, renamed)
SHA256: 84292c4128ae5baca4115d3f5049b9fee990d281cc8da6c7a57ea837cda7d239

libcef.dll (malicious loader)
SHA256: a48c0099a304d4e74ba03e3d593684b841592912852aafb563d9726e815a9e3d

icudtl.dat (ICU data + encrypted payload)
SHA256: 01ffce3ba619135750e1b8cfed6ab1b74b9d64b1c3f8eb30618f09dc7733b978

job.exe (decrypted .NET payload)
SHA256: 711b3f407d1f80ad7002dea228f62f4e1b04e4c8e58de5771d4a97c8e15dcca5

Full analysis below for anyone who wants the detail.

Initial download came from a Google Cloud Storage bucket:

hxxps://storage[.]googleapis[.]com/claudeapi/claude[.]html?msclkid=a5ca8dd81bbc1cea0dcee714b86f8877

The download is a bundle of three files that must sit together:

Claude.exe
libcef.dll
icudtl.dat

Claude.exe is not Claude. It's a legitimate JetBrains-signed JCEF helper, just renamed:

OriginalFilename: jcef_helper.exe
Version: 137.0.17.1107
Signer: JetBrains s.r.o.

It imports libcef.dll from its own folder, so the malicious libcef.dll runs under a valid signature. The fake DLL is unsigned, inflated to ~47 MB (probably to beat AV/sandbox size limits), has a mismatched 2023 timestamp, and imports mscoree.dll, which suggests it hosts the .NET runtime. I did not reverse the native loader itself.

The real payload is hidden in icudtl.dat. It's genuine ICU 72 data with ~31 KB appended after the last table entry. The blob decrypts with a 32-byte repeating XOR key into a .NET exe:

XOR key: 0ee17baf699b1f1540c4f157fcbf2373fe73ee2e1cb48dd4ce81fd2192fe58af
Result: job.exe (.NET assembly)

I decompiled job.exe. This is where all the behavior lives.

On startup it disables TLS cert validation, sets its working dir, and computes a victim ID:

Working dir: %LOCALAPPDATA%\Cache-<id>

Victim ID: first 4 bytes of SHA256(MachineName + UserName), hex

Two mutexes pick which branch runs:

Global\WinCacheSync   (normal instance)
Global\WinCacheSyncE  (elevated instance)

For C2 it uses EtherHiding, so there's no domain to block. It sends an eth_call to public BNB Smart Chain nodes, reads the bytes the contract returns, hex-decodes them, and XORs them to get a list of payload URLs:

Contract: 0xc1907d7be91f95903ad66d775c397302e7dd9228
Selector: 0x6d4ce63c
XOR key: deadbeefcafebabe13374269
RPC nodes:
  bsc-dataseed[.]binance[.]org
  bsc-dataseed1[.]defibit[.]io
  bsc-dataseed1[.]ninicoin[.]io

The operator can rotate the next stage just by updating the contract. The binary never changes.

It downloads each URL and runs it by type:

.exe -> u.exe  (run directly, hidden window)
.dll -> u.dll
else -> u.bin  (treated as tar, extracted to x\, every .exe inside launched)

Privilege escalation uses two methods. The first abuses the Steam Client Service. It copies its own side-load bundle into a temp folder and drops two VDF files:

%TEMP%\w<id>\launcher.exe   (the renamed JCEF host)
%TEMP%\w<id>\libcef.dll
%TEMP%\w<id>\icudtl.dat
%TEMP%\w<id>\signed.vdf      (Valve-signed Wallpaper Engine InstallScript, AppID 431960)
%TEMP%\w<id>\run.vdf

Then it talks to the SYSTEM level Steam service over its shared memory IPC to make the service run launcher.exe. Meainng, it restages its own sideload chain and has Steam execute it as SYSTEM.

Once it's SYSTEM, the second method kicks in. It forges a fresh primary token from the console user's token and launches with it:

NtCreateToken -> CreateProcessAsUser

If the Steam route fails, it falls back to a runas UAC prompt.

Defense evasion is a hidden PowerShell Defender exclusion:

powershell.exe -NoProfile -WindowStyle Hidden -Command "Add-MpPreference -ExclusionPath '...'"

Persistence is a scheduled task created through the Schedule.Service COM object:

Task name: CacheMaintenanceTask
Points at: %APPDATA%\Roaming\LocalCache\

The Exodus (crypto wallet) targeting plus the blockchain tradecraft points to crypto theft. I couldn't confirm the final payload, since it depends on what the contract returns at run time.