Russian Intel Targeting Signal & WhatsApp: Phishing Campaigns & Defensive Measures
Just saw the joint CISA/FBI advisory regarding Russian APT groups actively targeting Signal and WhatsApp. It looks like they aren't exploiting a zero-day in the Signal Protocol itself, but rather focusing on social engineering to intercept device linking—specifically phishing for those QR codes or SMS verification tokens to clone sessions.
Since they are targeting "high intelligence value" individuals, this isn't a spray-and-pray operation. It's highly targeted spear-phishing. While there isn't a specific CVE to patch here, detection is tricky because once the hijack is complete, the traffic to web.whatsapp.com or signal.org looks completely legitimate from the network layer.
We need to focus on the initial phish vector. If your users are hitting a fake portal, we need to catch the domain anomaly before the token is entered. I've been tuning our SIEM to look for suspicious traffic patterns associated with these lookalike domains.
Here is a basic Python snippet I’m using to scan proxy logs for domains that mimic these brands but use suspicious TLDs:
import tldextract
def check_suspicious_messaging_domain(url):
extracted = tldextract.extract(url)
domain = extracted.domain.lower()
suffix = extracted.suffix.lower()
# Legitimate TLDs for Signal/WhatsApp
safe_suffixes = ['com', 'org', 'net']
# Flag if brand name is used with a rare TLD
if domain in ['whatsapp', 'signal', 'telegram'] and suffix not in safe_suffixes:
return True
return False
Technically, the most effective control I've found is enforcing Signal Registration Lock and WhatsApp Two-Step Verification. Without the PIN, the SMS code alone isn't enough to hijack the account.
For those managing sensitive comms channels: Are you relying purely on user training to spot the QR code phish, or have you found a way to technically restrict device registration to managed mobile devices only?
We've moved to a 'Zero Trust' stance on mobile messaging apps for our C-suite. We're using Mobile Device Management (MDM) policies to block QR code scanning for Signal/WhatsApp unless the device is fully compliant and on a corporate network. It's a bit heavy-handed, but the risk of session hijacking via deep-faked login portals is just too high right now.
Good luck blocking QR scanning technically—users will just screenshot the code and upload it. I focus on the 'Safety Number' alert. In our phishing sims, we educate users that if they see a 'Safety Number Changed' notification, it implies an active Man-in-the-Middle or device registration attack. We've automated a alert via our SOAR playbook if the Signal desktop client logs a new device registration from a new IP geo-location.
Don't underestimate Signal's Registration Lock. Even if attackers successfully phish the SMS verification code, they cannot link the device without the user's PIN. This adds a critical layer of friction for the adversary. We also actively hunt for typosquatting domains used in these lures. You can use this basic KQL query to identify suspicious connections to look-alike domains in your proxy logs:
CommonSecurityLog
| where RequestURL contains "signal" or RequestURL contains "whatsapp"
| where isnotempty(DestinationPort)
| summarize Count() by SourceIP, RequestURL
Building on the targeted nature of this campaign: we assume the initial phishing succeeds. Therefore, we monitor for the post-exploitation tooling. Attackers often use Android emulators to accept the QR code and clone the session.
We deployed a simple hunt on endpoints to flag running virtualization processes that aren't approved. Here's a PowerShell snippet to check for common emulator signatures on user machines:
Get-Process | Where-Object {$_.ProcessName -match "qemu|nox|bluestacks|ldplayer"} | Select-Object ProcessName, Path
Catching the session creation tooling can alert you before the data exfiltration starts.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access