VENON: Analyzing the Rust Shift in LATAM Banking Trojans
Has anyone else been digging into the new VENON malware targeting Brazilian banks? It’s fascinating to see the LATAM cybercrime ecosystem moving away from the traditional Delphi-based malware (like Grandoreiro) to Rust. This shift isn't just aesthetic; Rust's memory safety features and complex control flow are making static analysis significantly more painful for researchers.
From a technical standpoint, VENON is a standard banking trojan relying on HTML overlays to harvest credentials. However, the use of Rust suggests these actors are preparing for more cross-platform capabilities or simply trying to bypass standard signature-based defenses that are tuned for older Delphi patterns. With 33 banks currently in the target list, the scope is massive.
We haven't identified specific CVEs being exploited for initial access yet—it seems to rely heavily on phishing—so detection relies heavily on behavioral analysis. I've been working on a YARA rule to catch potential variants by looking for Rust-specific string artifacts combined with Portuguese banking keywords.
yara rule Venon_Rust_Generic { meta: description = "Detects potential Rust-based banking trojan characteristics" author = "@SecArsenalUser" strings: // Common Rust allocator strings found in unstripped binaries $rust_alloc = "alloc::raw_vec" wide ascii $rust_std = "std::panicking" wide ascii // Specific banking keywords often found in overlay configs $bank_br = "banco" nocase $update = "atualizar" nocase // PT for 'update' condition: uint16(0) == 0x5A4D and 1 of ($rust_) and 1 of ($bank) }
I'm curious how everyone else is handling the rise of Rust malware. Are your current sandboxes successfully unpacking these binaries, or are you seeing a lot of timeouts due to the anti-analysis checks often bundled with Rust builds?
We've seen a few samples submitted to our sandbox, and you're right about the timeouts. The heavy obfuscation in Rust binaries is causing our automated analysis to hang. We've shifted focus to detecting the overlay injection mechanism rather than the binary itself.
We're monitoring for calls to SetWindowsHookEx and WriteProcessMemory originating from suspicious parent processes. It’s not foolproof, but it catches the overlay behavior regardless of the language used.
The switch from Delphi to Rust is a headache for legacy YARA rules. The string entropy is totally different. To add to your detection logic, I'd suggest adding a check for the overlay windows themselves.
You can use PowerShell to hunt for invisible top-level windows that might be hiding over legitimate banking apps:
Add-Type -TypeDefinition '
using System;
using System.Runtime.InteropServices;
public class Win32 {
[DllImport("user32.dll")]
public static extern bool IsWindowVisible(IntPtr hWnd);
}
'
Get-Process | Where-Object { $_.MainWindowHandle -ne 0 -and -not [Win32]::IsWindowVisible($_.MainWindowHandle) } | Select-Object ProcessName, Id
It's noisy, but if you filter for processes spawning from `explorer.exe` or browser launchers, it helps narrow it down.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access