Russian Ops Pivot to CMAs: Signal & WhatsApp Under Fire

The QR code vector is nasty because it bypasses the need for credentials entirely. In our red team exercises, we've had massive success using modified versions of open-source phishing kits to present 'Signal Desktop' login pages that actually just display a looped video of a QR code. The user scans it, and we own the session. Blocking the desktop clients is the only 100% mitigation I've found that doesn't break usability, provided you can enforce it via EDR policies.

From a SOC perspective, detection is incredibly difficult here. Since the traffic is end-to-end encrypted (E2EE), we can't inspect the payload. We are currently relying on heuristic detection of the devices themselves—flagging when a corporate mobile device tries to pair with a new desktop endpoint via QR. We push a notification to the user and the security team immediately if the 'Linked Devices' list changes.

We tackled this by rolling out mobile device management (MDM) profiles that explicitly disable the 'Show QR Code' feature in the app settings on managed devices. It's a bit of a friction point for users who legitimately want to use Signal Desktop at home, but for our high-risk users (HR, Execs, M&A), the trade-off is worth it. Combine that with strict conditional access policies, and you reduce the attack surface significantly.

For BYOD scenarios where MDM isn't an option, we drill users on the "Safety Number Change" notification. This is the critical alert that fires when a new session links; we treat any unexpected change as a potential breach. To supplement this, we identify devices running these desktop clients for risk scoring using Defender ATP:

DeviceProcessEvents
| where ProcessName has_any ("WhatsApp.exe", "Signal.exe")
| summarize count() by DeviceName, bin(Timestamp, 1d)

Excellent points on the technical vectors. From a physical security perspective, I want to highlight that QR-based attacks are significantly easier to execute without visual privacy controls. We’ve seen a rise in "shoulder surfing" incidents where attackers capture QR codes from unattended screens or over the shoulder in public spaces.

As a countermeasure, we’ve mandated privacy filters for all high-value employee devices and strictly enforced our clean desk policy to ensure linking screens aren't left open. It’s a low-tech fix, but it effectively neutralizes the line-of-sight requirement for many of these physical access exploits.

To expand on detection challenges: while E2EE blinds us to the messaging payload, we can still catch the initial access vector. The web traffic hosting the phishing QR code isn't usually encrypted. We've started hunting for specific User-Agent anomalies or keywords in proxy logs associated with known QRLjacking frameworks. You might try a simple query on your web proxy to spot the hosting infrastructure:

WebProxy | where Url contains "qr" and ResponseCode == 200 | distinct SrcIp, Url

This catches the setup before the session is even linked.

While E2EE limits payload visibility, we can monitor metadata and handshake anomalies. In my experience, legitimate linking often has specific TLS fingerprints (JA3 hashes). I recommend hunting for corporate desktop connections to signal.org or whatsapp.net that deviate from standard app signatures or originate from unexpected processes.

Here is a basic KQL query to start hunting for these anomalies:

DeviceNetworkEvents
| where RemoteUrl in ("whatsapp.net", "signal.org")
| where ActionType == "ConnectionSuccess"
| summarize Count = count() by DeviceName, InitiatingProcessFileName, RemoteUrl
| where Count > 10