Defending the Personal Link: Countering APT29's Signal & WhatsApp Phishing
Just caught the latest joint advisory from CISA and the FBI regarding Russian state-sponsored actors (likely APT29) pivoting to Commercial Messaging Applications (CMAs) like Signal and WhatsApp.
The core issue isn't compromising the E2EE protocol itself, but rather client-side trust. They are aggressively using QR code phishing to hijack sessions. Once a target scans the QR code hosted on the attacker's site, the "Link New Device" feature grants the attacker immediate access to the message history and contacts—effectively bypassing traditional MFA protections.
Since we can't natively monitor inside the Signal or WhatsApp traffic streams, we have to rely on monitoring the phishing infrastructure or the device behavior. Here is a basic KQL query to help identify potential lookalike domains or anomalies in proxy logs that might indicate a phishing kit in action:
let suspicious_tlds = dynamic([".xyz", ".top", ".tk", ".cc"]);
DeviceNetworkEvents
| where RemoteUrl contains "signal" or RemoteUrl contains "whatsapp"
| where RemoteUrl has_any (suspicious_tlds)
| extend ParsedUrl = parse_url(RemoteUrl)
| where not(ParsedUrl.Host has "signal.org" or ParsedUrl.Host has "whatsapp.com")
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName
| summarize Count=count() by RemoteUrl, DeviceName
For those managing mobile fleets, are you enforcing policies to restrict the camera app in specific network contexts, or is this purely a user awareness fight? I'm struggling to find a technical control that doesn't break usability for executives who need these apps for legitimate business comms.
You can't rely solely on domain reputation here. These groups are known for hosting their phishing kits on compromised legitimate WordPress sites or using cloud storage to serve the QR codes.
We've had luck focusing on the TLS JA3 fingerprint in our Zeek logs. Many of these kits use self-signed certs or unique cipher suites that stand out against standard traffic. Also, check for user-agents that are mobile browsers but hitting login endpoints in rapid succession—that's usually the victim reloading the page after the link times out.
User education is the only viable control right now. We run quarterly phishing simulations specifically targeting mobile habits (texting a 'link' rather than email).
From an MDM perspective, we use Microsoft Intune to require a PIN for app access and force Signal/WhatsApp data to be stored in the managed sandbox, but that doesn't stop the initial QR link attack. It only prevents the app data from being exfiltrated if the phone is physically lost or compromised by malware later.
It’s worth noting that once the device is linked, the attacker can see all future messages and some history, but they don't necessarily get the keys if the user has 'Registration Lock' enabled on Signal.
I'd advise pushing a config profile or policy (if supported by your vendor) or instructing users to enable Registration Lock (Signal) and Two-Step Verification (WhatsApp) immediately. It adds a PIN requirement that the attacker would need to bypass even after a successful QR hijack. It’s not a silver bullet, but it raises the bar.
Building on endpoint controls, if you permit these apps, monitor for configuration drift. A 'Linked Device' event immediately modifies local configuration files. Auditing these directories for recent changes can catch a hijack in progress.
For Signal on Windows, this one-liner checks for config modifications in the last 10 minutes:
Get-ChildItem "$env:APPDATA\Signal" -Recurse | Where-Object { $_.LastWriteTime -gt (Get-Date).AddMinutes(-10) }
If you see changes without a user-initiated update, investigate immediately.
To add an IAM layer, focus on the device context mismatch. When a user links a device via QR, it's often adding a desktop OS to a previously mobile-only identity footprint. If you use a CASB or SWG, alert on distinct operating systems accessing the same account simultaneously. For those using Sentinel, this KQL query helps spot a mobile account suddenly generating traffic from a Windows or Linux host:
CommonSecurityLog
| where Application in ("Signal", "WhatsApp")
| summarize Devices = make_set(DeviceOS) by User
| where array_length(Devices) > 1
It’s not a silver bullet, but it flags the event without needing endpoint agents.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access