BlueNoroff's Zoom Kit: Pre-Attack Crypto Wallet Profiling?
Has anyone dissected the new BlueNoroff campaign detailed in The Hacker News? They are evolving beyond simple ClickFix tactics. They are now utilizing a sophisticated phishing kit that targets Zoom and Microsoft Teams users.
What stands out to me is the pre-attack profiling. Before deploying the malware, the kit allegedly profiles the victim's crypto wallet to determine if they are a high-value target. This suggests a significant shift towards efficiency—saving their zero-day resources for the "whales."
They are leveraging "trust abuse" by utilizing previously compromised contacts within the same industry. This makes the phishing email bypass standard reputation checks because it comes from a known internal partner. Technical indicators often involve typosquatted domains like zoom-uus[.]com or fake Teams portals. The delivery mechanism typically relies on a fake browser update or meeting prompt that triggers a PowerShell download.
Here is a basic Sigma rule I’m drafting to catch the initial download stages from these suspicious parent processes:
title: BlueNoroff Zoom Phishing Kit Process Spawn
status: experimental
description: Detects suspicious PowerShell child processes spawned from browsers contacting typosquatted domains.
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|contains:
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
Image|endswith: '\powershell.exe'
CommandLine|contains:
- 'DownloadString'
- 'IEX'
filter_legit:
CommandLine|contains: 'official.zoom.us'
condition: selection and not filter_legit
level: high
How are you handling the social engineering aspect of this? With them using compromised industry contacts to send these invites, standard email filtering is struggling. Are you seeing success with browser isolation techniques for your finance teams?
We've seen a similar vector in the wild. The wallet profiling is usually done via JavaScript injected into the fake "Join Meeting" page. It checks for extensions like MetaMask or Phantom and attempts to read the balance via window.ethereum.
If the script returns a high value, it triggers the malicious msiexec or PowerShell command. If not, the user just gets a generic "Meeting ID not found" error, leaving them unaware they were targeted. It's incredibly stealthy. We've started enforcing strict browser extension policies for our finance team to mitigate the initial JS profiling phase.
From a detection standpoint, the network traffic is the tell. Even if they profile the wallet, they still need to C2 out or drop the payload eventually. I’d suggest looking for DNS anomalies. These kits rotate domains fast, but they often resolve to the same IP infrastructures.
We use a small Python script to hash the resolved IPs of non-standard Zoom domains and check them against known bad intel feeds. If you can block the C2 or the payload delivery domain at the DNS level, the wallet profiling doesn't matter much.
Valid point regarding DNS, Eve. Beyond the network layer, we should monitor the endpoint for the specific execution chain triggered post-validation. This kit often drops the payload via mshta or powershell spawned directly from the browser or meeting client. You can hunt for this behavior using a simple KQL query in Sentinel to find suspicious parent-child process relationships:
DeviceProcessEvents
| where InitiatingProcessName in~ ('chrome.exe', 'msedge.exe', 'Zoom.exe')
| where ProcessName in~ ('mshta.exe', 'powershell.exe')
| project Timestamp, DeviceName, InitiatingProcessName, ProcessCommandLine
This catches the execution even if they use domain fronting to hide C2 traffic.
Excellent breakdown of the execution chain. To catch this during the profiling phase, I’d recommend hunting for anomalous child processes spawned by collaboration apps. If teams.exe or chrome.exe directly spawns a shell without user interaction, that's a critical indicator. Here’s a KQL query to start hunting:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ('chrome.exe', 'msedge.exe', 'teams.exe')
| where FileName in~ ('powershell.exe', 'cmd.exe', 'mshta.exe')
This helps flag the initial compromise attempt before the payload lands.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access