Detecting TCLBANKER: Messaging Worms and Brazilian Banking Malware Shifts
Just reviewed the Elastic Security Labs report on REF3076 (TCLBANKER). It's interesting to see the evolution from the older Maverick trojan, specifically the revival of worm capabilities via WhatsApp and Outlook (tracked as SORVEPOTEL). Targeting 59 financial platforms is no joke, especially with the crypto integration.
One thing that stands out is the propagation method. We're used to seeing banking trojans spread via phishing, but using messaging apps as a worm vector changes the game. Since users trust messages from contacts, the infection rate is likely higher.
For those hunting this, here's a quick PowerShell snippet to check if Outlook is spawning suspicious child processes, a common IOC for this type of malware:
$outlook = Get-Process -Name outlook -ErrorAction SilentlyContinue
if ($outlook) {
Get-WmiObject Win32_Process | Where-Object { $_.ParentProcessId -eq $outlook.Id } |
Select-Object Name, ProcessId, CommandLine
}
We're seeing a lot of focus on blocking the C2s, but is anyone actively restricting WhatsApp Web or Outlook external functionality in their environments? It feels like a cat-and-mouse game with productivity vs. security. How are you handling the balance between allowing messaging apps and preventing worm propagation?
From a SOC perspective, we are pivoting away from just looking at email subject lines and focusing on process lineage. The worm capability means the initial infection vector might bypass standard gateways if the payload comes via a trusted messaging app. We've started using Sigma rules to flag outlook.exe spawning powershell.exe or cmd.exe immediately after receiving a file.
title: Outlook Spawning Shell
status: experimental
detection:
selection:
ParentImage|endswith: '\OUTLOOK.EXE'
Image|endswith:
- '\powershell.exe'
- '\cmd.exe'
condition: selection
It's noisy if you have add-ins, but for banking trojans like TCLBANKER, it's a necessary evil.
We're struggling with the WhatsApp vector. Our sales team relies heavily on WhatsApp Web for client communication. Blocking the domain isn't an option. We've implemented strict AppLocker policies to prevent the execution of unsigned binaries in the user profile directories, which should stop the dropped payload from running, but it feels fragile. Has anyone had success with network-based detection for the SORVEPOTEL worm specifically?
It's fascinating that they brought back the worm mechanic. I remember seeing similar tactics with VBScript worms years ago. The evolution to Brazilian banking trojans targeting crypto platforms suggests the threat actors are adapting to where the money is moving.
If you're pentesting, test your users' awareness by sending a 'fake' safe link via internal chat tools (with permission). You'd be surprised how many click it just because it came from a colleague, bypassing the 'suspicious email' filter in their brain.
Great insights on the AppLocker struggle. Since the worm abuses legitimate messaging APIs, monitoring for anomalous child processes is critical. We’ve flagged unexpected script hosts spawning directly from browser or mail clients. You can hunt for this behavior with the following KQL query:
DeviceProcessEvents
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "outlook.exe")
This helps catch the malware attempting to execute payloads post-click.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access