Phishing for E2EE: Russian Intel's Pivot to WhatsApp & Signal
Saw the new FBI/CISA advisory this morning regarding Russian state-sponsored actors targeting Commercial Messaging Applications (CMAs) like Signal and WhatsApp. This isn't just credential theft; they are aiming for full account takeovers, likely via 'device linking' attacks where users are tricked into scanning a QR code generated by the threat actor.
Since E2EE makes content inspection impossible, we have to focus on the enrollment phase. We need to monitor for unexpected access to the Web Client interfaces. Here is a basic KQL query to flag browser processes launching the specific Web URLs, which might indicate an automated script or a user falling for a phishing link:
DeviceNetworkEvents
| where RemoteUrl in~ ("web.whatsapp.com", "signal.me", "signal.org")
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe")
| where ActionType == "ConnectionSuccess"
| summarize count() by DeviceName, RemoteUrl, InitiatingProcessFileName, bin(Timestamp, 5m)
| where count_ > 10 // Threshold for potential automation or rapid retry
Given that these platforms are often used for operational security by the very targets these actors are after (journalists, gov officials), how are you handling the balance between usability (web clients) and security (desktop apps only)? Are you blocking web client access entirely for high-risk users?
We enforce Signal Desktop strictly via GPO/MSI and block web.signal.me at the proxy. It’s a bit draconian, but it eliminates the QR code vector entirely. The desktop app at least verifies device linkage via phone notification, which adds a layer of friction the attacker has to bypass. You can't rely on users to recognize a cloned QR code interface—they look identical.
The advisory mentions APT29 specifically. If you're seeing this traffic, you should check your logs for specific user-agents. Automation tools used for these attacks often stick out because they miss the nuances of a real browser telemetry.
grep -iE 'signal|whatsapp' /var/log/nginx/access.log | awk '{print $12}' | sort | uniq -c | sort -nr
If you see a generic Python-Requests or Selenium user-agent hitting those endpoints, burn it down immediately.
From a red team perspective, the hardest part isn't the tech—it's the social engineering. Getting a target to pull out their phone and scan a code is high friction. However, if the threat actor has already compromised the email, a fake 'Security Alert: Link your device to verify identity' email works surprisingly well. User education is really the only patch for this specific vector.
Blocking the web client is a solid first step, Sarah, but we also need to account for mobile-to-mobile linking vectors which bypass that proxy restriction. We've found value in leveraging our MDM to push compliance policies that require re-authentication if the device is jailbroken or rooted, though that's reactive.
To proactively catch these, we've started ingesting logs from our SWG into the SIEM to look for rapid DNS requests to known CMA infrastructure endpoints, which often precede the linking attempt.
NetworkEvent
| where DeviceCategory == "Mobile"
| where UrlCategories has_cs ("Social Networking")
| summarize count() by bin(Timestamp, 5m), SourceIp
| where count_ > 50
Has anyone had success with Mobile Threat Defense (MTD) tools actually blocking the QR generation screen itself?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access