OkoBot: Injecting Seed Phishers into Legit Hardware Wallet Apps
Just caught the report on the OkoBot framework, and it’s a textbook example of why we can't rely solely on 'verified' downloads anymore. This malware has been active since April 2025, specifically targeting Windows hosts to intercept hardware wallet interactions.
The scary part isn't that it's stealing credentials; it's the method. OkoBot performs process injection into the official desktop applications (Ledger Live and Trezor Suite). It waits for the user to plug in the hardware device, then injects a fake 'recovery phrase' prompt directly into the legitimate app window. The user sees the real UI, trusted branding, and valid SSL certificates, but the input field is compromised.
Since this relies on manipulating the live process memory, standard signature-based AV might miss it if the payload is obfuscated. I'm recommending teams look for anomaly-based detection on high-value financial workstations. Specifically, monitor for unsigned DLLs loading into these wallet processes.
You can audit your current environment with this quick PowerShell snippet to check for unverified modules loaded into the Ledger process:
$targetProcess = "Ledger Live"
Get-Process -Name $targetProcess -ErrorAction SilentlyContinue | ForEach-Object {
$_.Modules | Where-Object { -not $_.SignatureStatus.IsValid } |
Select-Object FileName, @{Name="Signed";Expression={$_.SignatureStatus}}
}
How are you all handling air-gapped verification for clients who refuse to operate offline?
This is exactly why I advocate for dedicated transaction-signing machines (like a Tails USB stick) for any client holding significant assets. If the OS is ephemeral, malware persistence like OkoBot becomes irrelevant. However, for everyday users, this is brutal. I'd add checking for suspicious child processes spawned by the wallet apps, as OkoBot likely needs a loader to establish the injection hook first.
From a SOC perspective, we've started flagging 'UI Accessibility' tools being opened by finance apps. Malware often uses UI Automation to read screens or inject elements. If Ledger Live starts spawning explorer.exe hooks or accessing user32.dll excessively outside of normal startup, we're treating it as critical. Behavioral baselines are saving us here more than hash checks.
Good catch on the module auditing. I'd also suggest enforcing AppLocker or Windows Defender Application Control (WDAC) policies to only allow signed binaries to load into specific sensitive directories. If OkoBot tries to inject an unsigned DLL, the policy should block the execution. It's a bit of management overhead, but it stops this specific attack vector dead in its tracks.
Building on Mike's suggestion, process injection often opens new network sockets. Since OkoBot hooks into the wallet app, we should monitor for anomalous outbound connections from signed binaries like Ledger Live. You can quickly audit this behavior with PowerShell:
Get-NetTCPConnection -OwningProcess (Get-Process -Name "Ledger Live").Id | Select-Object RemoteAddress, State
If the verified app is communicating with unknown IPs, that’s a massive red flag.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access